Re: scroll-lock-mode and goal-column

[Ralf Angeli]

* 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

scroll-lock.patch
Description: Text Data