From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: yank-handler Date: 13 Feb 2004 17:15:12 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200402130352.i1D3qhk27180@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1076685642 12985 80.91.224.253 (13 Feb 2004 15:20:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2004 15:20:42 +0000 (UTC) Cc: Takaaki.Ota@am.sony.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Feb 13 16:20:32 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 1Arf7I-0006ZW-00 for ; Fri, 13 Feb 2004 16:20:32 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Arf7H-0004aw-00 for ; Fri, 13 Feb 2004 16:20:32 +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 1Arf6E-0008BN-6L for emacs-devel@quimby.gnus.org; Fri, 13 Feb 2004 10:19:26 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Arf5q-0008An-97 for emacs-devel@gnu.org; Fri, 13 Feb 2004 10:19:02 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Arf2H-0007PI-Mu for emacs-devel@gnu.org; Fri, 13 Feb 2004 10:15:53 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.24) id 1Arf2G-0007Oh-OP for emacs-devel@gnu.org; Fri, 13 Feb 2004 10:15:20 -0500 Original-Received: (qmail 66803 invoked from network); 13 Feb 2004 15:15:17 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 13 Feb 2004 15:15:17 -0000 Original-To: Luc Teirlinck In-Reply-To: <200402130352.i1D3qhk27180@raven.dms.auburn.edu> Original-Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:19914 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19914 Luc Teirlinck writes: > Revision 1372 of subr.el drastically changed the behavior of > `insert-for-yank', but made no supporting changes in `kill-new'. Good catch, Luc! > 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'. Yes, that seems to be the logical choice. > > If desired, I could, of course, commit the trivial patch below. Please do! > > _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 don't think there are any uses of the yank-handler undo feature yet. Actually, table.el seems to be the only usage of yank-handlers, and it doesn't even seem to use more than very basic features of it. In any case, as long as we haven't made a final 22.x release, we are free to fix it anyway we feel necessary. > 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. I think it is necessary to build a list of undo functions and the region they apply to, rather than just a single yank-undo-function. I don't have time to work on it though. Still, the yank-handler functionality may need more general rework (I recall Stefan making some comments about it a while back). > Maybe one just will have to be extremely > careful when specifying 4-part yank-handlers. I think that will always be true -- yank-handler can make a lot of problems if done carelessly.