* bug#12401: scroll-preserve-screen-position broken with font height faces @ 2012-09-10 6:12 Le Wang 2012-09-10 7:23 ` Eli Zaretskii 2022-02-09 9:17 ` Lars Ingebrigtsen 0 siblings, 2 replies; 12+ messages in thread From: Le Wang @ 2012-09-10 6:12 UTC (permalink / raw) To: 12401 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-10 6:12 bug#12401: scroll-preserve-screen-position broken with font height faces Le Wang @ 2012-09-10 7:23 ` Eli Zaretskii 2012-09-10 12:37 ` Le Wang 2012-09-10 13:26 ` Stefan Monnier 2022-02-09 9:17 ` Lars Ingebrigtsen 1 sibling, 2 replies; 12+ messages in thread From: Eli Zaretskii @ 2012-09-10 7:23 UTC (permalink / raw) To: Le Wang; +Cc: 12401 > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-10 7:23 ` Eli Zaretskii @ 2012-09-10 12:37 ` Le Wang 2012-09-10 18:02 ` Eli Zaretskii 2012-09-10 13:26 ` Stefan Monnier 1 sibling, 1 reply; 12+ messages in thread From: Le Wang @ 2012-09-10 12:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12401 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-10 12:37 ` Le Wang @ 2012-09-10 18:02 ` Eli Zaretskii 0 siblings, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2012-09-10 18:02 UTC (permalink / raw) To: Le Wang; +Cc: 12401 > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-10 7:23 ` Eli Zaretskii 2012-09-10 12:37 ` Le Wang @ 2012-09-10 13:26 ` Stefan Monnier 2012-09-10 18:05 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2012-09-10 13:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12401, Le Wang > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-10 13:26 ` Stefan Monnier @ 2012-09-10 18:05 ` Eli Zaretskii 2012-09-10 20:42 ` Stefan Monnier 2012-09-12 8:08 ` martin rudalics 0 siblings, 2 replies; 12+ messages in thread From: Eli Zaretskii @ 2012-09-10 18:05 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12401, l26wang > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-10 18:05 ` Eli Zaretskii @ 2012-09-10 20:42 ` Stefan Monnier 2012-09-12 8:08 ` martin rudalics 1 sibling, 0 replies; 12+ messages in thread From: Stefan Monnier @ 2012-09-10 20:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12401, l26wang >> > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-10 18:05 ` Eli Zaretskii 2012-09-10 20:42 ` Stefan Monnier @ 2012-09-12 8:08 ` martin rudalics 2012-09-12 16:48 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: martin rudalics @ 2012-09-12 8:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12401, l26wang >>> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-12 8:08 ` martin rudalics @ 2012-09-12 16:48 ` Eli Zaretskii 2012-09-12 17:38 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2012-09-12 16:48 UTC (permalink / raw) To: martin rudalics; +Cc: 12401, l26wang > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-12 16:48 ` Eli Zaretskii @ 2012-09-12 17:38 ` martin rudalics 0 siblings, 0 replies; 12+ messages in thread From: martin rudalics @ 2012-09-12 17:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12401, l26wang > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2012-09-10 6:12 bug#12401: scroll-preserve-screen-position broken with font height faces Le Wang 2012-09-10 7:23 ` Eli Zaretskii @ 2022-02-09 9:17 ` Lars Ingebrigtsen 2022-03-09 16:22 ` Lars Ingebrigtsen 1 sibling, 1 reply; 12+ messages in thread From: Lars Ingebrigtsen @ 2022-02-09 9:17 UTC (permalink / raw) To: Le Wang; +Cc: 12401 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12401: scroll-preserve-screen-position broken with font height faces 2022-02-09 9:17 ` Lars Ingebrigtsen @ 2022-03-09 16:22 ` Lars Ingebrigtsen 0 siblings, 0 replies; 12+ messages in thread From: Lars Ingebrigtsen @ 2022-03-09 16:22 UTC (permalink / raw) To: Le Wang; +Cc: 12401 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-03-09 16:22 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-10 6:12 bug#12401: scroll-preserve-screen-position broken with font height faces Le Wang 2012-09-10 7:23 ` Eli Zaretskii 2012-09-10 12:37 ` Le Wang 2012-09-10 18:02 ` Eli Zaretskii 2012-09-10 13:26 ` Stefan Monnier 2012-09-10 18:05 ` Eli Zaretskii 2012-09-10 20:42 ` Stefan Monnier 2012-09-12 8:08 ` martin rudalics 2012-09-12 16:48 ` Eli Zaretskii 2012-09-12 17:38 ` martin rudalics 2022-02-09 9:17 ` Lars Ingebrigtsen 2022-03-09 16:22 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.