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: Various simple.el patches Date: Fri, 23 May 2003 12:06:41 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200305231706.h4NH6fN11684@eel.dms.auburn.edu> References: <200305132031.h4DKVp58013718@rum.cs.yale.edu> <84llx9hhwp.fsf@lucy.is.informatik.uni-duisburg.de> <20030514124245.GA24487@gnu.org> <843cjhtytp.fsf@lucy.is.informatik.uni-duisburg.de> <20030514144839.GA6241@gnu.org> <844r3xr0ar.fsf@lucy.is.informatik.uni-duisburg.de> <84fznfzb9t.fsf@lucy.is.informatik.uni-duisburg.de> <84k7co464e.fsf@lucy.is.informatik.uni-duisburg.de> <200305220252.h4M2q9W10068@eel.dms.auburn.edu> <200305231351.h4NDpqAc030488@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1053713222 12157 80.91.224.249 (23 May 2003 18:07:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 23 May 2003 18:07:02 +0000 (UTC) Cc: kai.grossjohann@gmx.net Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 23 20:06:59 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19JGqc-0002MA-00 for ; Fri, 23 May 2003 20:00:54 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19JH2T-000550-00 for ; Fri, 23 May 2003 20:13:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19JGRL-00062C-V5 for emacs-devel@quimby.gnus.org; Fri, 23 May 2003 13:34:47 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19JG0z-0006on-6I for emacs-devel@gnu.org; Fri, 23 May 2003 13:07:33 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19JG0c-0006bJ-9d for emacs-devel@gnu.org; Fri, 23 May 2003 13:07:11 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19JG09-0006Pj-C5 for emacs-devel@gnu.org; Fri, 23 May 2003 13:06:41 -0400 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) h4NH6coc014884; Fri, 23 May 2003 12:06:38 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.11.6+Sun/8.11.6) id h4NH6fN11684; Fri, 23 May 2003 12:06:41 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier+gnu/emacs@rum.cs.yale.edu In-reply-to: <200305231351.h4NDpqAc030488@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) Original-cc: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14142 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14142 Stefan Monnier wrote: > The following version of kill-whole-line should work OK with the > kill-ring, including read-only buffers, and with invisible text. I'd really like to see it implemented as a wrapper around kill-line. After all, it seems that the bug you're fixing also plagues kill-line when `kill-whole-line' is set, so it should be fixed there too. To make sure we understand each other: we are talking about the bug with the kill ring handling. I was unable to produce such bugs with kill-line while kill-whole-line is set to t. Can you produce such bugs? It is easy to actually produce such bugs while trying to implement one's own versions of the function kill-whole-line using the variable kill-whole-line. But I believe that the point of the variable is that you can do C-a C-k C-k... instead of C-a and then double the amount of C-k's. It is clear to the user that the C-a is going to "break" the kill-ring and start a new entry. I'd really like to see it implemented as a wrapper around kill-line. This is a matter of taste. Kai originally implemented it as such, but also seemed to suggest that he thought it might be better to use only kill-region. My fix for the kill-ring handling indeed would work just as fine for a kill-line based function. My version of kill-whole-line allows for a M--1 S- C-x z z z... functionality which sometimes can be useful. I guess that, one way or the other, it should be possible to get the same effect with a kill-line based function. But kill-line is very much a user level function with plenty of special features. Use of kill-line would make `kill-whole-line' vulnerable to any change or addition to the user level features of kill-line. I prefer using the more primitive kill-region. Sincerely, Luc.