[Top][All Lists]

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

Re: find-file and backward-kill-word

From: David Kastrup
Subject: Re: find-file and backward-kill-word
Date: Tue, 12 Oct 2004 15:22:49 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

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

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

reply via email to

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