Re: find-file and backward-kill-word

[David Kastrup]

Luc Teirlinck <address@hidden> writes:

> 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.

An error stops a complex editing operation in the course of a Lisp
program or keyboard macro before it does half-baked nonsensical
things.

I don't want complex operations to merrily complete "successfully"
after having done a number of incomplete steps.  Improving the error
message is ok, but not at the cost of dropping the error.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum