[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Luc Teirlinck
Subject: Re: vc-follow-symlinks confirm message is not read only
Date: Fri, 7 May 2004 20:07:21 -0500 (CDT)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]