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

[martin rudalics <rudalics@gmx.at>]

 > 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