[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
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
- find-file and backward-kill-word, Reinhard Kotucha, 2004/10/11
- Re: find-file and backward-kill-word, Luc Teirlinck, 2004/10/11
- Re: find-file and backward-kill-word, Alan Shutko, 2004/10/12
- Re: find-file and backward-kill-word, Reinhard Kotucha, 2004/10/12
- Re: find-file and backward-kill-word, Luc Teirlinck, 2004/10/12
- Re: find-file and backward-kill-word, Alan Shutko, 2004/10/13
- Re: find-file and backward-kill-word, Richard Stallman, 2004/10/14
- Re: find-file and backward-kill-word, Stefan Daschek, 2004/10/16