From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Question about intended behavior of 'insert-for-yank-1'. Date: Mon, 12 Sep 2016 12:15:22 -0500 Message-ID: <87inu1ghud.fsf@red-bean.com> References: <874m5lr92d.fsf@red-bean.com> <83eg4p9hqk.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1473700595 25582 195.159.176.226 (12 Sep 2016 17:16:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Sep 2016 17:16:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 12 19:16:30 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 1bjUqM-00067I-KP for ged-emacs-devel@m.gmane.org; Mon, 12 Sep 2016 19:16:30 +0200 Original-Received: from localhost ([::1]:44287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUqK-0002NL-MT for ged-emacs-devel@m.gmane.org; Mon, 12 Sep 2016 13:16:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUpO-0002LX-Az for emacs-devel@gnu.org; Mon, 12 Sep 2016 13:15:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjUpJ-0005Gu-91 for emacs-devel@gnu.org; Mon, 12 Sep 2016 13:15:30 -0400 Original-Received: from mail-oi0-x231.google.com ([2607:f8b0:4003:c06::231]:35379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUpJ-0005GB-4H; Mon, 12 Sep 2016 13:15:25 -0400 Original-Received: by mail-oi0-x231.google.com with SMTP id d191so107962996oih.2; Mon, 12 Sep 2016 10:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version; bh=oWu4holFhPXE1wiNhsCyLL3QLuGY/2mcmg7I7HG0jTI=; b=o6JHdpqEQbx6jr77KMdLVNbBJEjhl6pJ4iPsrun4Kr9yIUWkat/nayo5s5iSsbrnqM 09L0M+PKGnRYo7RGz8rPM7SSUq9vKbYb43UTWNh83gP7wztYa7IuC/BHtknWGCaPEXs4 HX8pfDgjWlN239902mhjUde+AF+KAi5CaQWOut2zSYJ8fYZEs7AdDPOYrCsx2/tWTyO6 Wqqia4BM1627WkvVNohcPpE0/Sbl6Xbax8HttNDYFFTRxEztUbVCdV18bLX/hl0qWl3d +uPHNO8NzqaNXXZHcJUO3vuRpkBq3bIGKWPmkD56jZ5PJj1ctt/f1h+Ltxkl8/JeIAzy N6Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:reply-to :date:in-reply-to:message-id:user-agent:mime-version; bh=oWu4holFhPXE1wiNhsCyLL3QLuGY/2mcmg7I7HG0jTI=; b=PVIrFgwC3irtT08cYdv9JVWj3+SWQch7cu6bK6rz5uOvkDwUuyRWZWP+T1R8ojMuKw mc/4Ixr5vRbfNcu4Tz/gEpAZaF5ACAOVbfIPBqHGV1bD7/cuDq6kstej2ds03+QbK/kf HTQ7nzTAUOpjpB7d0PchaMY8LhiPwACFK5bdUJD6PNwOFNOs+tzuGiLL0J5z8bOx/PLB 0q93Vb9Q5coXn3jJuDSnFK5RPlryw4qKBgV6+MukLHrVNgRbeAon5RPH4wLrGKmzLoOp UJklcAZSMbiCgWJSn4JJpqC7erHAGQSRwBL98mp1DlBOK7PLan/kvuEZfxTIVKL9lFCZ dFnA== X-Gm-Message-State: AE9vXwPuxDxu0iPrljZ79/iHPBm6J5cNgS/jmHaG7lmB115IL3KN/6S3WPsCOwsW7oaEiw== X-Received: by 10.202.216.212 with SMTP id p203mr62465oig.110.1473700524402; Mon, 12 Sep 2016 10:15:24 -0700 (PDT) Original-Received: from kwork (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id f9sm409926itc.10.2016.09.12.10.15.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Sep 2016 10:15:22 -0700 (PDT) In-Reply-To: <83eg4p9hqk.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Sep 2016 19:59:31 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c06::231 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:207390 Archived-At: Eli Zaretskii writes: >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. Thanks, Eli. Yes, that's true, but note that the doc string for `insert-for-yank' just refers the reader to `insert-for-yank-1' for details. The only doc string where the STRING-passing behavior is discussed is the doc string of `insert-for-yank-1', and that doc string indicates, or strongly implies, that the entirety of STRING is passed (which it isn't). >> (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? Sure. But I'm concerned with the behavior that can be figured out just from reading the documentation, since that's what the documentation is for. Many things become clear from reading the code and from trying experiments, but I hadn't gone that far yet. My assertion is just that the documentation alone does not give the user enough information to predict how these functions will behave. As per above, that still seems true to me. >I see no problem with how the functions behave. As for documentation, >can you show the change you had in mind? Something about how the string passed is actually the first extent of string covered by the property assuming the property starts at character 0. I haven't worded it yet; that takes time and I first wanted to make sure there was agreement that there is a *documentation* problem here rather than a code-behavior problem. Are you saying that in your view there is no documentation deficiency here? Best regards, -Karl