scroll-lock-mode and goal-column

scroll-lock-mode and goal-column

[Stefan Monnier]

Now that scroll-preserve-screen-position preserves the column position,
I think that scroll-lock-mode can be simplified to not mess with the
goal-column any more.  Could someone look into this?


        Stefan

Re: scroll-lock-mode and goal-column

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Now that scroll-preserve-screen-position preserves the column position,
> I think that scroll-lock-mode can be simplified to not mess with the
> goal-column any more.  Could someone look into this?

Im not convinced that scroll-preserve-screen-position _can_ preserve the
column position.

In the times where only fixed width characters existed, goal-column
served the function of maintaining a column position even when one was
moving temporarily across lines that had no "point" corresponding to a
previous goal column.

For preserving screen positions in the presence of variable width fonts,
we really need a goal-pixel-position instead in order to have a
comparable preservation of movement.  Otherwise, moving back and forth
"visually" across a line with a larger font, or just moving vertically
across proportionally spaced fonts will make us lose track of the actual
position.

-- 
David Kastrup

Re: scroll-lock-mode and goal-column

[Stefan Monnier]

>> Now that scroll-preserve-screen-position preserves the column position,
>> I think that scroll-lock-mode can be simplified to not mess with the
>> goal-column any more.  Could someone look into this?

> Im not convinced that scroll-preserve-screen-position _can_ preserve the
> column position.

"Soyez réaliste, demandez l'impossible!"

AFAIK, it *does* preserve the (pixel) column position.


        Stefan

Re: scroll-lock-mode and goal-column

[Ralf Angeli]

* Stefan Monnier (2008-06-13) writes:

> Now that scroll-preserve-screen-position preserves the column position,
> I think that scroll-lock-mode can be simplified to not mess with the
> goal-column any more.  Could someone look into this?

After removing all calls to `scroll-lock-update-goal-column' and
`scroll-lock-move-to-column' the behavior is not the same as before.

For example if you open the info dir with `C-h i d', activate Scroll
Lock mode, move point down a bit into the introductory blurb, then move
it to column 30 and scroll down line by line with `C-n', point will
sometimes stick to column 0 even though there is text to the right where
it can be moved to.  Also, it will not jump back to column 30, once it
does, but to column 26.

With the manual column adjustment in scroll-lock.el, point will be
positioned correctly at column 30 again, when it is possible.

I'm not sure if the behavior exhibited with using only
`scroll-preserve-screen-position' is intentional, but it looks like a
bug.  The build I checked this with is about a week old.

-- 
Ralf

Re: scroll-lock-mode and goal-column

[Stefan Monnier]

> For example if you open the info dir with `C-h i d', activate Scroll
> Lock mode, move point down a bit into the introductory blurb, then move
> it to column 30 and scroll down line by line with `C-n', point will
> sometimes stick to column 0 even though there is text to the right where
> it can be moved to.

Most likely, `last-command' is not among '(scroll-up scroll-down) so the
C code doesn't understand that it should preserve the column position
from before the last command.

> Also, it will not jump back to column 30, once it
> does, but to column 26.

Sounds very strange, indeed.  But Info buffers have funny contents, so
maybe you were in column 0 on a big display-property space that spanned
columns from 0 to 26?


        Stefan

Re: scroll-lock-mode and goal-column

[Ralf Angeli]

* Stefan Monnier (2008-06-29) writes:

>> For example if you open the info dir with `C-h i d', activate Scroll
>> Lock mode, move point down a bit into the introductory blurb, then move
>> it to column 30 and scroll down line by line with `C-n', point will
>> sometimes stick to column 0 even though there is text to the right where
>> it can be moved to.
>
> Most likely, `last-command' is not among '(scroll-up scroll-down) so the
> C code doesn't understand that it should preserve the column position
> from before the last command.

Can I make the C code acquainted with the functions of scroll-lock.el?
If this is what would remedy the situation.  I'm a bit confused because
in scroll-lock.el, the goal column is updated if `last-command' is _not_
among the scrolling functions.

>> Also, it will not jump back to column 30, once it
>> does, but to column 26.
>
> Sounds very strange, indeed.  But Info buffers have funny contents, so
> maybe you were in column 0 on a big display-property space that spanned
> columns from 0 to 26?

There are no display properties, AFAICS.  And if I open the raw dir file
the behavior is even worse, meaning point will not jump back into the
previous column at all once it got stuck to column 0.

-- 
Ralf

Re: scroll-lock-mode and goal-column

[Stefan Monnier]

>>> For example if you open the info dir with `C-h i d', activate Scroll
>>> Lock mode, move point down a bit into the introductory blurb, then move
>>> it to column 30 and scroll down line by line with `C-n', point will
>>> sometimes stick to column 0 even though there is text to the right where
>>> it can be moved to.
>> 
>> Most likely, `last-command' is not among '(scroll-up scroll-down) so the
>> C code doesn't understand that it should preserve the column position
>> from before the last command.

> Can I make the C code acquainted with the functions of scroll-lock.el?

Not directly, no.  Maybe we should add a variable for that.
Othrwise, you can either set this-command to `scroll-up' (since it's
later on mvoes to last-command), or you can let-bind last-command
appropriately around the calls to scroll-up/down.

> If this is what would remedy the situation.  I'm a bit confused because
> in scroll-lock.el, the goal column is updated if `last-command' is _not_
> among the scrolling functions.

updated = changed = not preserved.

I understand that since we're talking about preserving something used to
preserve something else, it's not very clear.

>> Sounds very strange, indeed.  But Info buffers have funny contents, so
>> maybe you were in column 0 on a big display-property space that spanned
>> columns from 0 to 26?
> There are no display properties, AFAICS.

I'm pretty sure they're there: they're used for alignemnt.  But indeed
C-u C-x = has trouble finding them because there are insible spaces
before them.

> And if I open the raw dir file the behavior is even worse, meaning
> point will not jump back into the previous column at all once it got
> stuck to column 0.

I actually much prefer this behavior because it's consistent with the
simple `last-command' problem, so it should be easy to fix.


        Stefan

Re: scroll-lock-mode and goal-column

[Ralf Angeli]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

* Stefan Monnier (2008-06-29) writes:

>> Can I make the C code acquainted with the functions of scroll-lock.el?
>
> Not directly, no.  Maybe we should add a variable for that.
> Othrwise, you can either set this-command to `scroll-up' (since it's
> later on mvoes to last-command), or you can let-bind last-command
> appropriately around the calls to scroll-up/down.
>
>> If this is what would remedy the situation.  I'm a bit confused because
>> in scroll-lock.el, the goal column is updated if `last-command' is _not_
>> among the scrolling functions.
>
> updated = changed = not preserved.

Ugh, I should stop answering messages when in a hurry.

>> And if I open the raw dir file the behavior is even worse, meaning
>> point will not jump back into the previous column at all once it got
>> stuck to column 0.
>
> I actually much prefer this behavior because it's consistent with the
> simple `last-command' problem, so it should be easy to fix.

I'm not sure what to let-bind `last-command' to, but setting
`this-command' seems to work.  (See attached patch.  No ChangeLog entry,
because I don't think this should be applied.)

The only problem now is that once the `forward-line' movement kicks in
at the start or end of a buffer, point will be moved to column 0 again.
However, I'd prefer the column to be preserved.  Since this behavior of
`forward-line' is by design, I'm not sure if we can get rid of the
manual preservation of the goal column.  `vertical-motion' obviously has
a similar behavior and I did not find an alternative function for moving
by lines that keeps the goal column, nor did I find an option which
could be set in order for `forward-line' to change behavior.

-- 
Ralf

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: scroll-lock.patch --]
[-- Type: text/x-diff, Size: 2972 bytes --]

Index: scroll-lock.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/scroll-lock.el,v
retrieving revision 1.10
diff -u -r1.10 scroll-lock.el
--- scroll-lock.el	6 May 2008 07:57:49 -0000	1.10
+++ scroll-lock.el	30 Jun 2008 20:04:03 -0000
@@ -63,63 +63,44 @@
     (setq scroll-preserve-screen-position
 	  scroll-lock-preserve-screen-pos-save)))
 
-(defun scroll-lock-update-goal-column ()
-  "Update `scroll-lock-temporary-goal-column' if necessary."
-  (unless (memq last-command '(scroll-lock-next-line
-			       scroll-lock-previous-line
-			       scroll-lock-forward-paragraph
-			       scroll-lock-backward-paragraph))
-    (setq scroll-lock-temporary-goal-column (current-column))))
-
-(defun scroll-lock-move-to-column (column)
-  "Like `move-to-column' but cater for wrapped lines."
-  (if (or (bolp)
-	  ;; Start of a screen line.
-	  (not (zerop (mod (- (point) (line-beginning-position))
-			   (window-width)))))
-      (move-to-column column)
-    (forward-char (min column (- (line-end-position) (point))))))
-
 (defun scroll-lock-next-line (&optional arg)
   "Scroll up ARG lines keeping point fixed."
   (interactive "p")
   (or arg (setq arg 1))
-  (scroll-lock-update-goal-column)
   (if (pos-visible-in-window-p (point-max))
       (forward-line arg)
-    (scroll-up arg))
-  (scroll-lock-move-to-column scroll-lock-temporary-goal-column))
+    (scroll-up arg)
+    (setq this-command 'scroll-up)))
 
 (defun scroll-lock-previous-line (&optional arg)
   "Scroll up ARG lines keeping point fixed."
   (interactive "p")
   (or arg (setq arg 1))
-  (scroll-lock-update-goal-column)
   (condition-case nil
-      (scroll-down arg)
-    (beginning-of-buffer (forward-line (- arg))))
-  (scroll-lock-move-to-column scroll-lock-temporary-goal-column))
+      (progn
+	(scroll-down arg)
+	(setq this-command 'scroll-down))
+    (beginning-of-buffer (forward-line (- arg)))))
 
 (defun scroll-lock-forward-paragraph (&optional arg)
   "Scroll down ARG paragraphs keeping point fixed."
   (interactive "p")
   (or arg (setq arg 1))
-  (scroll-lock-update-goal-column)
   (scroll-up (count-screen-lines (point) (save-excursion
 					   (forward-paragraph arg)
 					   (point))))
-  (scroll-lock-move-to-column scroll-lock-temporary-goal-column))
+  (setq this-command 'scroll-up))
 
 (defun scroll-lock-backward-paragraph (&optional arg)
   "Scroll up ARG paragraphs keeping point fixed."
   (interactive "p")
   (or arg (setq arg 1))
-  (scroll-lock-update-goal-column)
   (let ((goal (save-excursion (backward-paragraph arg) (point))))
     (condition-case nil
-	(scroll-down (count-screen-lines goal (point)))
-      (beginning-of-buffer (goto-char goal))))
-  (scroll-lock-move-to-column scroll-lock-temporary-goal-column))
+	(progn
+	  (scroll-down (count-screen-lines goal (point)))
+	  (setq this-command 'scroll-down))
+      (beginning-of-buffer (goto-char goal)))))
 
 (provide 'scroll-lock)
 

Re: scroll-lock-mode and goal-column

[Stefan Monnier]

>>> And if I open the raw dir file the behavior is even worse, meaning
>>> point will not jump back into the previous column at all once it got
>>> stuck to column 0.
>> 
>> I actually much prefer this behavior because it's consistent with the
>> simple `last-command' problem, so it should be easy to fix.

> I'm not sure what to let-bind `last-command' to, but setting

Any of `scroll-up' or `scroll-down'.

> `this-command' seems to work.  (See attached patch.  No ChangeLog entry,

Yes, it should work as well.

> The only problem now is that once the `forward-line' movement kicks in
> at the start or end of a buffer, point will be moved to column 0 again.

Oh, indeed.  That needs more work.

> However, I'd prefer the column to be preserved.  Since this behavior of
> `forward-line' is by design, I'm not sure if we can get rid of the
> manual preservation of the goal column.

How 'bout using next-line?


        Stefan

Re: scroll-lock-mode and goal-column

[Ralf Angeli]

* Stefan Monnier (2008-07-04) writes:

>> However, I'd prefer the column to be preserved.  Since this behavior of
>> `forward-line' is by design, I'm not sure if we can get rid of the
>> manual preservation of the goal column.
>
> How 'bout using next-line?

Not much better.  It sometimes happens that when the last command was
`scroll-up' and the next one is `next-line', i.e. the bottom of the
buffer is reached, the goal column will not be preserved if point is not
at the original goal column but e.g. at the start of the line.  So it
looks as if `next-line' is unaware of the goal column being in effect
for `scroll-up'.

There are other funny things going on sometimes, though they don't seem
to be related to `next-line' because they happen with `forward-line' as
well.  Start Emacs with `emacs -Q', type `C-h i d', enable Scroll Lock
mode, type `M-<' to put point at the start of the buffer, scroll up with
`C-n' till point is just below the "* Menu" line, then scroll down with
`C-p' till point reaches the start of the buffer (the line with
"(dir)Top".  Once this happens, point jumps back down to the first
content line after "* Menu" which is "* Info..." here.  (This is with
the patched version of scroll-mode.el.  Not sure if this happens with
the unpatched one as well.)

-- 
Ralf