bug#12401: scroll-preserve-screen-position broken with font height faces

bug#12401: scroll-preserve-screen-position broken with font height faces

[Le Wang]

with "scroll-preserve-screen-position" set to t, pressing <C-v>, <M-v>
brings point back to the same buffer position.

However if I customize a face e.g. font-lock-keyword-face with height
of 1.3, then this no longer works.  Browsing any emacs-lisp source,
<C-v>, <M-v> changes line position.

For reference this package works just fine with variable height faces:
http://www.cs.utah.edu/~eeide/emacs/scroll-in-place.el.gz

I would like to not load extra packages if this functionality is
already in Emacs though.

-- 
Le

bug#12401: scroll-preserve-screen-position broken with font height faces

[Eli Zaretskii]

> Date: Mon, 10 Sep 2012 14:12:39 +0800
> From: Le Wang <l26wang@gmail.com>
> 
> with "scroll-preserve-screen-position" set to t, pressing <C-v>, <M-v>
> brings point back to the same buffer position.
> 
> However if I customize a face e.g. font-lock-keyword-face with height
> of 1.3, then this no longer works.  Browsing any emacs-lisp source,
> <C-v>, <M-v> changes line position.

scroll-preserve-screen-position tries to preserve the
_screen_position_ of point, i.e. where you find the cursor, after it
executes one of the scrolling commands.  But since arbitrary pixel
coordinates on the screen might in general (in the presence of
variable-size fonts) correspond to one of 2 possible text lines, Emacs
needs to choose where to put the cursor.  What exactly do you expect
Emacs to do in such a situation, where it simply _cannot_ keep the
same pixel coordinates?

IOW, what is the "contract" that you expect Emacs to keep under
scroll-preserve-screen-position?  Is it just that doing N C-v's
followed by N M-v's brings point to the same location where it was
before this sequence of 2N commands?  Or do you also expect something
from each individual C-v/M-v, and if so, what exactly?

> For reference this package works just fine with variable height faces:
> http://www.cs.utah.edu/~eeide/emacs/scroll-in-place.el.gz

I cannot use it, neither in Emacs 24.2 nor in the current trunk code:
it complains about a missing function screen-width.  Please provide a
complete recipe for using this package, starting with "emacs -Q", in
Emacs 24.2 or newer, so I could study what it does and how.

For that matter, please also provide all the details collected by
report-emacs-bug, they might be important.

Thanks.

bug#12401: scroll-preserve-screen-position broken with font height faces

[Le Wang]

Thanks for the quick response, Eli.

On Mon, Sep 10, 2012 at 3:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> scroll-preserve-screen-position tries to preserve the
> _screen_position_ of point, i.e. where you find the cursor, after it
> executes one of the scrolling commands.  But since arbitrary pixel
> coordinates on the screen might in general (in the presence of
> variable-size fonts) correspond to one of 2 possible text lines, Emacs
> needs to choose where to put the cursor.  What exactly do you expect
> Emacs to do in such a situation, where it simply _cannot_ keep the
> same pixel coordinates?

I understand the problem.

> IOW, what is the "contract" that you expect Emacs to keep under
> scroll-preserve-screen-position?  Is it just that doing N C-v's
> followed by N M-v's brings point to the same location where it was
> before this sequence of 2N commands?  Or do you also expect something
> from each individual C-v/M-v, and if so, what exactly?

The contract should be C-v followed by M-v should bring the point back
to the same line.  If the max_column after C-v is less than
current_column, then either restoring the column as current_column or
max_column is acceptable.

Although the current behaviour of C-p followed by C-n seems to restore
current_column, so that would be more consistent.

As a corrolary, if this contract is enforced then N C-v followed by N
M-v should also bring point back to the same line.


>> For reference this package works just fine with variable height faces:
>> http://www.cs.utah.edu/~eeide/emacs/scroll-in-place.el.gz
>
> I cannot use it, neither in Emacs 24.2 nor in the current trunk code:
> it complains about a missing function screen-width.  Please provide a
> complete recipe for using this package, starting with "emacs -Q", in
> Emacs 24.2 or newer, so I could study what it does and how.

Sorry about this.  It seems the version I use comes from XEmacs and
I've made a small fix.  I've placed it here:

https://gist.github.com/3690403



> For that matter, please also provide all the details collected by
> report-emacs-bug, they might be important.

The repro steps I've described starts from "emacs -Q".  I can still
provide this information, if needed though.


-- 
Le

bug#12401: scroll-preserve-screen-position broken with font height faces

[Eli Zaretskii]

> Date: Mon, 10 Sep 2012 20:37:06 +0800
> From: Le Wang <l26wang@gmail.com>
> Cc: 12401@debbugs.gnu.org
> 
> Thanks for the quick response, Eli.
> 
> On Mon, Sep 10, 2012 at 3:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > scroll-preserve-screen-position tries to preserve the
> > _screen_position_ of point, i.e. where you find the cursor, after it
> > executes one of the scrolling commands.  But since arbitrary pixel
> > coordinates on the screen might in general (in the presence of
> > variable-size fonts) correspond to one of 2 possible text lines, Emacs
> > needs to choose where to put the cursor.  What exactly do you expect
> > Emacs to do in such a situation, where it simply _cannot_ keep the
> > same pixel coordinates?
> 
> I understand the problem.
> 
> > IOW, what is the "contract" that you expect Emacs to keep under
> > scroll-preserve-screen-position?  Is it just that doing N C-v's
> > followed by N M-v's brings point to the same location where it was
> > before this sequence of 2N commands?  Or do you also expect something
> > from each individual C-v/M-v, and if so, what exactly?
> 
> The contract should be C-v followed by M-v should bring the point back
> to the same line.

Then that feature is not currently available in Emacs scrolling,
sorry.  scroll-preserve-screen-position simply puts the point at or
near the same screen position after the window is scrolled.  That is
all it does.  The manual says that this returns to the previous point
when you scroll back, but that promise has no basis.  When some faces
are higher than the default font, the way Emacs scrolls windows cannot
make sure you will return to the same place.  It can only work when
all the faces use fonts that are no higher than the default face.

> >> For reference this package works just fine with variable height faces:
> >> http://www.cs.utah.edu/~eeide/emacs/scroll-in-place.el.gz
> >
> > I cannot use it, neither in Emacs 24.2 nor in the current trunk code:
> > it complains about a missing function screen-width.  Please provide a
> > complete recipe for using this package, starting with "emacs -Q", in
> > Emacs 24.2 or newer, so I could study what it does and how.
> 
> Sorry about this.  It seems the version I use comes from XEmacs and
> I've made a small fix.  I've placed it here:
> 
> https://gist.github.com/3690403

This package uses an entirely different method of scrolling, one that
is based on lines, not pixels.  I wonder how well it works when
(large) images, display strings, invisible text, and other calamities
are present in the buffer.  In any case, using such a method would
mean a thorough rewrite of window-scrolling primitives.  Volunteers
welcome.

bug#12401: scroll-preserve-screen-position broken with font height faces

[Stefan Monnier]

> scroll-preserve-screen-position?  Is it just that doing N C-v's
> followed by N M-v's brings point to the same location where it was
> before this sequence of 2N commands?

I think this should be the main point, yes.


        Stefan

bug#12401: scroll-preserve-screen-position broken with font height faces

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Le Wang <l26wang@gmail.com>,  12401@debbugs.gnu.org
> Date: Mon, 10 Sep 2012 09:26:42 -0400
> 
> > scroll-preserve-screen-position?  Is it just that doing N C-v's
> > followed by N M-v's brings point to the same location where it was
> > before this sequence of 2N commands?
> 
> I think this should be the main point, yes.

For this to work, we would need to make sure that C-v followed by M-v
end up with a window that has the same window-start as the one before
C-v.  But this is impossible to ensure with the way we compute
window-start, because the move_it family of functions used for that
can only move forward; therefore moving back is necessarily
implemented differently, and the results differ when variable-size
fonts are present.

IOW, this is a limitation of the current design of the
window-scrolling functions that can only be lifted by redesigning.

bug#12401: scroll-preserve-screen-position broken with font height faces

[Stefan Monnier]

>> > scroll-preserve-screen-position?  Is it just that doing N C-v's
>> > followed by N M-v's brings point to the same location where it was
>> > before this sequence of 2N commands?
>> I think this should be the main point, yes.
> For this to work, we would need to make sure that C-v followed by M-v
> end up with a window that has the same window-start as the one before
> C-v.  But this is impossible to ensure with the way we compute
> window-start, because the move_it family of functions used for that
> can only move forward; therefore moving back is necessarily
> implemented differently, and the results differ when variable-size
> fonts are present.

Indeed.

> IOW, this is a limitation of the current design of the
> window-scrolling functions that can only be lifted by redesigning.

Yup,


        Stefan

bug#12401: scroll-preserve-screen-position broken with font height faces

[martin rudalics]

 >>> scroll-preserve-screen-position?  Is it just that doing N C-v's
 >>> followed by N M-v's brings point to the same location where it was
 >>> before this sequence of 2N commands?
 >> I think this should be the main point, yes.
 >
 > For this to work, we would need to make sure that C-v followed by M-v
 > end up with a window that has the same window-start as the one before
 > C-v.

Why?

 > But this is impossible to ensure with the way we compute
 > window-start, because the move_it family of functions used for that
 > can only move forward; therefore moving back is necessarily
 > implemented differently, and the results differ when variable-size
 > fonts are present.
 >
 > IOW, this is a limitation of the current design of the
 > window-scrolling functions that can only be lifted by redesigning.

I'm completely happy with the following solution: Whenever, after a
sequence of scrolling commands, the original position (that is the
position before the sequence started) reappears in a window, move to
that position and leave the window start position alone.  See also

http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html

martin

bug#12401: scroll-preserve-screen-position broken with font height faces

[Eli Zaretskii]

> Date: Wed, 12 Sep 2012 10:08:48 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, 12401@debbugs.gnu.org, 
>  l26wang@gmail.com
> 
>  >>> scroll-preserve-screen-position?  Is it just that doing N C-v's
>  >>> followed by N M-v's brings point to the same location where it was
>  >>> before this sequence of 2N commands?
>  >> I think this should be the main point, yes.
>  >
>  > For this to work, we would need to make sure that C-v followed by M-v
>  > end up with a window that has the same window-start as the one before
>  > C-v.
> 
> Why?

Because all scroll-preserve-screen-position does is put point on
certain window-relative pixel coordinates.  For this to follow a
repeatable series of point values, you need the series of window-start
positions to be repeatable, too.

IOW, if you start with point P1 and window-start W1, and do a C-v
followed by M-v, then setting point at the same pixel distance from
the left-top window edge will get you back to P1 iff the window-start
gets back at W1.

>  > But this is impossible to ensure with the way we compute
>  > window-start, because the move_it family of functions used for that
>  > can only move forward; therefore moving back is necessarily
>  > implemented differently, and the results differ when variable-size
>  > fonts are present.
>  >
>  > IOW, this is a limitation of the current design of the
>  > window-scrolling functions that can only be lifted by redesigning.
> 
> I'm completely happy with the following solution: Whenever, after a
> sequence of scrolling commands, the original position (that is the
> position before the sequence started) reappears in a window, move to
> that position and leave the window start position alone.  See also
> 
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html

Fine by me.  However, the OP asked if there's an existing feature in
Emacs that can satisfy this need.  After looking into this, my
response was that no, there's no such a feature.  (The fact that
setting scroll-preserve-screen-position is documented in the manual as
providing this feature is, I suspect, a remnant from the old display
engine that only supported fixed fonts.)

The solution you propose, and another one implemented in
scroll-in-place.el, is OK, and indeed this is better done in Lisp than
in C.

bug#12401: scroll-preserve-screen-position broken with font height faces

[martin rudalics]

 > Because all scroll-preserve-screen-position does is put point on
 > certain window-relative pixel coordinates.  For this to follow a
 > repeatable series of point values, you need the series of window-start
 > positions to be repeatable, too.
 >
 > IOW, if you start with point P1 and window-start W1, and do a C-v
 > followed by M-v, then setting point at the same pixel distance from
 > the left-top window edge will get you back to P1 iff the window-start
 > gets back at W1.

Yes.  Given the constraints of `scroll-preserve-screen-position' I
understand you now.

martin

bug#12401: scroll-preserve-screen-position broken with font height faces

[Lars Ingebrigtsen]

Le Wang <l26wang@gmail.com> writes:

> with "scroll-preserve-screen-position" set to t, pressing <C-v>, <M-v>
> brings point back to the same buffer position.
>
> However if I customize a face e.g. font-lock-keyword-face with height
> of 1.3, then this no longer works.  Browsing any emacs-lisp source,
> <C-v>, <M-v> changes line position.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I tried reproducing this in Emacs 29, and it seems to basically work
fine -- hitting `C-v' and `M-v' seems to retain its position.

Do you still see this problem in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12401: scroll-preserve-screen-position broken with font height faces

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I tried reproducing this in Emacs 29, and it seems to basically work
> fine -- hitting `C-v' and `M-v' seems to retain its position.
>
> Do you still see this problem in recent Emacs versions?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no