From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Question about intended behavior of 'insert-for-yank-1'. Date: Mon, 12 Sep 2016 19:59:31 +0300 Message-ID: <83eg4p9hqk.fsf@gnu.org> References: <874m5lr92d.fsf@red-bean.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1473699612 1543 195.159.176.226 (12 Sep 2016 17:00:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Sep 2016 17:00:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 12 19:00:08 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjUaW-0008MF-2J for ged-emacs-devel@m.gmane.org; Mon, 12 Sep 2016 19:00:08 +0200 Original-Received: from localhost ([::1]:44202 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUaU-0001QU-7u for ged-emacs-devel@m.gmane.org; Mon, 12 Sep 2016 13:00:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUZy-0001QP-Hc for emacs-devel@gnu.org; Mon, 12 Sep 2016 12:59:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjUZu-0007Tw-CM for emacs-devel@gnu.org; Mon, 12 Sep 2016 12:59:33 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUZu-0007Tp-8g; Mon, 12 Sep 2016 12:59:30 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1875 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjUZt-0004u2-7h; Mon, 12 Sep 2016 12:59:29 -0400 In-reply-to: <874m5lr92d.fsf@red-bean.com> (message from Karl Fogel on Mon, 12 Sep 2016 00:17:14 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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 Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207386 Archived-At: > From: Karl Fogel > Date: Mon, 12 Sep 2016 00:17:14 -0500 > > The doc string for 'insert-for-yank-1' says: > > [...] > If STRING has a non-nil ‘yank-handler’ property on its first > character, the normal insert behavior is altered. The value of > the ‘yank-handler’ property must be a list of one to four > elements, of the form (FUNCTION PARAM NOEXCLUDE UNDO). > FUNCTION, if non-nil, should be a function of one argument, an > object to insert; it is called instead of ‘insert’. > PARAM, if present and non-nil, replaces STRING as the argument to > FUNCTION or ‘insert’; e.g. if FUNCTION is ‘yank-rectangle’, PARAM > may be a list of strings to insert as a rectangle. > [...] > > This implies that when the `yank-handler' property is present, then when PARAM is nil, the string passed to FUNCTION should be STRING. That is, the entire length of STRING, even if the `yank-handler' property is set only on STRING's first character. > > However, the way it actually behaves is that if you set the property on (say) exactly the first character of STRING, then, assuming you rely on the implicit parameter passing, what gets passed to FUNCTION is a string consisting of just the first character of STRING :-). Later, when you yank with C-y, that's all you'll get. But for insert-for-yank-1, STRING is its argument, and it's that argument that gets passed to FUNCTION. So I don't see how the doc string of this subroutine is inaccurate or misleading. The part that tricked you is in insert-for-yank: (defun insert-for-yank (string) "Call `insert-for-yank-1' repetitively for each `yank-handler' segment. See `insert-for-yank-1' for more details." (let (to) (while (setq to (next-single-property-change 0 'yank-handler string)) (insert-for-yank-1 (substring string 0 to)) <<<<<<<<<<< (setq string (substring string to)))) (insert-for-yank-1 string)) It passes to insert-for-yank-1 the substring of its argument STRING that was actually "covered" by the text property. See also the while loop. > Should I update the documentation to clarify? Or should the behavior change instead? I see no problem with how the functions behave. As for documentation, can you show the change you had in mind? > (By the way, I have not tested what happens if you set that property on multiple disjoint extents of STRING. Does FUNCTION get passed a newly-created concatenation of all the stretches of string that had the property? I have no idea. If the recommendation here is just to fix the documentation, though, then I'll do that testing.) Isn't that clear from the loop in insert-for-yank? Or am I missing something? Thanks.