From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: find-file and backward-kill-word Date: Tue, 12 Oct 2004 08:06:14 -0500 (CDT) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200410121306.i9CD6Eh17567@raven.dms.auburn.edu> References: <16746.62602.225874.363145@zarniwoop.ms25.local> <200410120059.i9C0x3O16263@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1097586476 21310 80.91.229.6 (12 Oct 2004 13:07:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 12 Oct 2004 13:07:56 +0000 (UTC) Cc: reinhard.kotucha@web.de, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 12 15:07:42 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CHMNR-0006vl-00 for ; Tue, 12 Oct 2004 15:07:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CHMUQ-0008VN-Ae for ged-emacs-devel@m.gmane.org; Tue, 12 Oct 2004 09:14:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CHMUG-0008UJ-Mu for emacs-devel@gnu.org; Tue, 12 Oct 2004 09:14:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CHMUF-0008Tq-Uq for emacs-devel@gnu.org; Tue, 12 Oct 2004 09:14:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CHMUF-0008Tf-QS for emacs-devel@gnu.org; Tue, 12 Oct 2004 09:14:43 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CHMN4-0004ts-UC; Tue, 12 Oct 2004 09:07:19 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i9CD7HiU022417; Tue, 12 Oct 2004 08:07:18 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id i9CD6Eh17567; Tue, 12 Oct 2004 08:06:14 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: dak@gnu.org In-reply-to: (message from David Kastrup on Tue, 12 Oct 2004 10:31:41 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28292 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28292 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: #", 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.