Re: vc-follow-symlinks confirm message is not read only

[Luc Teirlinck]

Stefan Monnier wrote:

   > find-file-noselect-1 binds inhibit-read-only to t, probably for very
   > good reasons.

   Well, the reasons aren't good enough to keep it bound that long.

   > !     (let ((inhibit-read-only nil))
   > !       (run-hooks 'find-file-hook))))

   That's just very ugly.  We should instead change the scope of the binding
   such that it only covers the place where inhibit-read-only should indeed
   be t.

   When was this problem, introduced?

If "this problem" means the actual concrete reported problem, probably
when the minibuffer prompt became an actual part of the minibuffer.
If it means the fact that find-file-noselect-1 binds inhibit-read-only
to t over the entire scope of the function, that was already the case
when find-file-noselect-1 was first introduced, about six years ago.

In as far as the places where inhibit-read-only should be t, it must
be t at least for the call to erase-buffer (unless one would change
that function as suggested).  I guess it probably must be t at other
places too, since otherwise it probably just would have been bound to
t around that call.  find-file-noselect-1 calls quite a lot of stuff
and inhibit-read-only is dynamically bound to t in all those calls.
It may not always be obvious (at least not to me) whether that should
be the case or not.

Sincerely,

Luc.