Re: find-file-hook, recenter, scroll-conservatively and save-place

[martin rudalics]

> I don't like the default recentering too.  I had to fix it with
> a lot of customization, e.g.
>
> (add-hook 'xref-after-jump-hook 'reposition-window)
> (add-hook 'xref-after-return-hook 'reposition-window)
> (add-hook 'find-function-after-hook 'reposition-window)

Once you get used to recentering you probably like it.  I never
managed to like it.  It's a consequence of our insistence to keep
point on-screen.

>> That is, provide 'window-point' and 'window-start' action alist entries
>> with the former allowing the 'switch-to-buffer-preserve-window-point'
>> logic (among others) and the latter optionally allowing to recenter.
>
> Like switch-to-buffer-preserve-window-point used in dired-find-file?

More like we handle 'display-buffer-mark-dedicated' now.  That is,
'switch-to-buffer-preserve-window-point' would be respected by
'display-buffer' unless explicitly overridden by a 'window-point'
entry.  But I dislike the idea of adding yet another variable that
will be eventually handled like an alist entry.

> Interesting question.  Maybe introduce two new buffer-local variables
> 'window-point' and 'window-start' that a hook could set and then
> display-buffer could read and call functions window-point and window-start?
> These buffer-local values should be used only once and should be reverted
> to nil after the first use.

Basically, anyone who wants to customize the behavior may bind
'display-buffer-alist' appropriately around the 'find-file' call.  But
this is awkward.  Alists are not very suitable to "affect just this
'display-buffer' call".

> BTW, a related question: should save-place save window-start as well?
> It should be easy to implement after this problem is solved.

I have no practice with 'save-place-mode' so I can't tell.  From my
experience I can only tell that it's disorienting when reverting a
buffer doesn't preserve window start.

martin