Re: find-file and backward-kill-word

[Luc Teirlinck]

David Kastrup wrote:

   Perhaps we should not move the cursor when "killing" readonly
   material?  It would have the disadvantage that using kill-word three
   times will not copy three words into the kill buffer, but I don't
   think that killing readonly text is used so often that we need to
   provide this sort of "convenience".  If we signal an error, I don't
   think we should really move point, either.

I kill text in read-only buffers all the time.  On the other hand, I
would hope that people would not try to edit read-only buffers
countless times each day.  Having to reposition point in such a,
hopefully rare, case is not a major inconvenience.  It is not like
loosing editing, mistakenly deleting files, unknowingly breaking hard
links or the like.

On the other hand, I do not know why the default value of
`kill-read-only-ok' is nil.  I believe that what causes confusion is
that the error message is misleading and does not tell the user what
really happened.  We not only moved point, but also copied text to the
kill ring.  We _have_ to tell the user that, or the next yank will be
a much bigger surprise than the point motion.  If `kill-read-only-ok'
is t, the message you get is "Read only text copied to kill ring"
which tells you exactly what happened.  If `kill-read-only-ok' is nil
you get "Buffer is read-only: #<buffer *info*>", which is misleading,
since it suggests that nothing happened.

I believe that we should not just change the default of
`kill-read-only-ok' to t, I believe we could quite as well eliminate
the variable and hardcode the `t' behavior.  The `nil' behavior makes
no sense.

Sincerely,

Luc.