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: yank-handler Date: Thu, 12 Feb 2004 21:52:43 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200402130352.i1D3qhk27180@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1076644517 11928 80.91.224.253 (13 Feb 2004 03:55:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2004 03:55:17 +0000 (UTC) Cc: Takaaki.Ota@am.sony.com Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Feb 13 04:55:06 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ArUPx-0005GZ-00 for ; Fri, 13 Feb 2004 04:55:05 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ArUPx-0004Dj-00 for ; Fri, 13 Feb 2004 04:55:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ArUOf-00015d-7r for emacs-devel@quimby.gnus.org; Thu, 12 Feb 2004 22:53:45 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ArUOb-00015X-DX for emacs-devel@gnu.org; Thu, 12 Feb 2004 22:53:41 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ArUO5-0000uZ-79 for emacs-devel@gnu.org; Thu, 12 Feb 2004 22:53:40 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ArUO4-0000j4-Br for emacs-devel@gnu.org; Thu, 12 Feb 2004 22:53:08 -0500 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 i1D3qvKt025568; Thu, 12 Feb 2004 21:52:58 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id i1D3qhk27180; Thu, 12 Feb 2004 21:52:43 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19907 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19907 Revision 1372 of subr.el drastically changed the behavior of `insert-for-yank', but made no supporting changes in `kill-new'. Such supporting changes are necessary as the ielm run below shows: ===File ~/killielm========================================== *** Welcome to IELM *** Type (describe-mode) for help. ELISP> (kill-new "01234" nil '(ignore)) nil ELISP> kill-ring (#("01234" 0 1 (yank-handler (ignore)) 1 5 nil)) ELISP> ;; C-y gives: 1234 ELISP> (kill-append "56789" t '(ignore)) nil ELISP> kill-ring (#("5678901234" 0 1 (yank-handler (ignore)) 1 5 nil 5 6 (yank-handler (ignore)) 6 10 nil)) ELISP> ;; C-y gives: 67891234============================================================ As before, `kill-new' only sets the yank-handler property of the _first_ character of the string, because it considers that to be representative of the entire string. But `insert-for-yank' now only considers it to be representative for that first character itself and the resulting behavior makes no sense. The following trivial change to `kill-new' would eliminate the "miscommunication" between `kill-new' and `insert-for-yank'. It remains to be decided what the behavior of `kill-append' ought to be. If we _only_ make the change below, then `kill-append' returns to its pre-revision-1372 behavior if called with a non-nil yank-handler argument: the yank-handler argument applies to both parts of the string. That seems good. If no explicit yank-handler argument is specified the old behavior was that the yank-handler was set to nil for the entire result string if the new string was prepended and the yank-handler of the old string applied to the entire string if the new string was appended: the first character was what mattered. Without further changes, the patch below would keep all yank handlers of the old string in place, whereas the new string would get no yank-handler. This independently of whether the new string got prepended or appended. That behavior might actually make more sense, given the new "philosophy" of `insert-for-yank'. If desired, I could, of course, commit the trivial patch below. _However_, without further changes, the UNDO specified by the _last_ yank-handler region always seems to win for the _entire_ yank. I do not feel comfortable at all about this, although I know of no concrete bugs resulting from it. I suspect the latter might just be due to the fact that 4-part yank-handlers are not used very often in the Emacs source code. I can not immediately think of _any_ safe way to handle competing UNDO's however. Maybe one just will have to be extremely careful when specifying 4-part yank-handlers. ===File ~/simple-diff======================================= *** simple.el.~1.629.~ Wed Feb 11 22:08:18 2004 --- simple.el Thu Feb 12 20:36:09 2004 *************** *** 1842,1848 **** argument should still be a \"useful\" string for such uses." (if (> (length string) 0) (if yank-handler ! (put-text-property 0 1 'yank-handler yank-handler string)) (if yank-handler (signal 'args-out-of-range (list string "yank-handler specified for empty string")))) --- 1842,1849 ---- argument should still be a \"useful\" string for such uses." (if (> (length string) 0) (if yank-handler ! (put-text-property 0 (length string) ! 'yank-handler yank-handler string)) (if yank-handler (signal 'args-out-of-range (list string "yank-handler specified for empty string")))) ============================================================