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

[Gergely Risko <gergely@risko.hu>]

Hi,

After more digging:
  - find-file-* calls find-file-noselect
  - find-file-noselect always returns a buffer
  - find-file-noselect doesn't return the information if this is a new
    buffer just visiting a file right now or an old one that was open
  - find-file-* then selects the returned buffer and chooses a window,
    displays the window, etc.

The hook that I need (something like find-file-with-window-hook) can
be described like this: similar to find-file-hook, but called after a
window has been chosen or created as necessary and the window's buffer
has been changed to the buffer being opened.  This hook would
guarantee in its documentation that:

  current-buffer === (window-buffer (current-window))

This new hook can be run-hook'd at the end of the various find-file-*
user facing commands.

The communication between the find-file-noselect function and
the find-file-* user facing commands can be implemented in two ways:
  - return some kind of structured data from find-file-noselect (with
    the buffer and my new boolean about "is this a new buffer?")
  - setq a buffer local variable inside find-file-noselect that is
    later queried at the end of the find-file-* commands to decide
    whether to run the find-file-with-window-hook or not.

Conceptually the first sounds cleaner and better, but
find-file-noselect is a function that is documented and therefore this
would been a breaking change.

Therefore I prefer solution 2.

A third alternative would be to rename find-file-noselect to
find-file--noselect-internal, implement my API and provide a backward
compatibility find-file-noselect function.

Any opinions on the mentioned designs?  Which should I go ahead with
and prepare a patch or does anyone have a simpler/better idea or any
other suggestion?  Also, please tell me if this is already a solved
issue and I'm just being dense. :-)

Cheers,
Gergely