From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Damien Cassou Newsgroups: gmane.emacs.devel Subject: Re: hierarchy-print doesn't allow sending indent-string arg to hierarchy-map Date: Wed, 02 Aug 2023 17:48:14 +0200 Message-ID: <87h6phmon5.fsf@cassou.me> References: <87a5vi4piz.fsf@cassou.me> <87jzuh2abv.fsf@cassou.me> <4a9152a4-3aff-3550-e967-e77a1c9307dc@riseup.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37242"; mail-complaints-to="usenet@ciao.gmane.io" To: mousebot , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 02 17:51:48 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qRE8Z-0009SY-W2 for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Aug 2023 17:51:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qRE7q-0002GP-3V; Wed, 02 Aug 2023 11:51:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRE5M-0000yB-08 for emacs-devel@gnu.org; Wed, 02 Aug 2023 11:48:28 -0400 Original-Received: from mail.choca.pics ([2001:910:1410:500::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRE5K-00086H-4J for emacs-devel@gnu.org; Wed, 02 Aug 2023 11:48:27 -0400 Original-Received: from localhost (localhost.localdomain [IPv6:::1]) by mail.choca.pics (Postfix) with ESMTP id 819E218192DE6; Wed, 2 Aug 2023 17:48:21 +0200 (CEST) Original-Received: from mail.choca.pics ([IPv6:::1]) by localhost (mail.choca.pics [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id ujvKk29z6Lb5; Wed, 2 Aug 2023 17:48:20 +0200 (CEST) Original-Received: from localhost (localhost.localdomain [IPv6:::1]) by mail.choca.pics (Postfix) with ESMTP id 92A4F18192DEC; Wed, 2 Aug 2023 17:48:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at choca.pics Original-Received: from mail.choca.pics ([IPv6:::1]) by localhost (mail.choca.pics [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id hYFhcuvAIp6e; Wed, 2 Aug 2023 17:48:20 +0200 (CEST) Original-Received: from localhost (unknown [IPv6:2a01:cb19:ca5:9400:e443:3f0d:ed50:c0fa]) by mail.choca.pics (Postfix) with ESMTPSA id F3FFA18192DE6; Wed, 2 Aug 2023 17:48:19 +0200 (CEST) In-Reply-To: <4a9152a4-3aff-3550-e967-e77a1c9307dc@riseup.net> Received-SPF: pass client-ip=2001:910:1410:500::1; envelope-from=damien@cassou.me; helo=mail.choca.pics X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 02 Aug 2023 11:51:00 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308246 Archived-At: mousebot writes: > perhaps there is some other code it run it against also? I don't understand this sentence. > a patch is attached, formatted with magit from a magit diff. is that > applicable, or is a different format required? Patches should usually be based on the root of the project so I would expect to see "a/lisp/emacs-lisp/hierarchy.el" instead of "a/hierarchy.el" in the patch. Also, the patch shouldn't be a plain diff but should also contain information that the commit needs (e.g., author, date, message). To create a patch, my approach is to first create a dedicated branch, then a commit (with a proper message) and finally to ask Magit to generate a patch for the commit (with "M-x magit-patch-create" or "W c c" and the cursor on the commit in the Magit status buffer). Please read "** Commit messages" in the CONTRIBUTE file at the root of the emacs tree to know how to write your commit message. > --- a/hierarchy.el > +++ b/hierarchy.el > @@ -475,10 +475,31 @@ indentation value (a number) as input." > > Use TO-STRING to convert each element to a string. TO-STRING is > a function taking an item of HIERARCHY as input and returning a > -string. If nil, TO-STRING defaults to a call to `format' with \"%s\"." > +string. I think the last sentence should be kept, it still makes sense. > + > +Calls `hierarchy-print-line' with `hierarchy-labelfn-indent' as > +second argument." This is an implementation detail we don't to mention here. What is not an implementation detail is that the hierarchy's elements are indented with a 2-space string. We could add a sentence about that. We could also reference the new function `hierarchy-print-line' to tell the user that this later one gives more configuration freedom but is a little more complicated to use. > (let ((to-string (or to-string (lambda (item) (format "%s" > item))))) > + (hierarchy-print-line > + hierarchy > + (hierarchy-labelfn-indent > + (lambda (item _) > + (funcall to-string item)))))) > + > +(defun hierarchy-print-line (hierarchy &optional labelfn) > + "Insert HIERARCHY in current buffer as plain text. > + > +Use LABELFN to convert each element to a string. LABELFN is > +a function taking an item of HIERARCHY as input "as well as an indentation level as number". > and returning a > +string. If nil, LABELFN defaults to a call to `format' with \"%s\". I don't think LABELFN should have a default value in this function. It is lower-level than hierarchy-print. Also, the user will have to customize it in many cases to get indentation. > + > +This function is not responsible for indentation, but it can be > +achieved by providing a function such as > +`hierarchy-labelfun-indent' for LABELFN." > + (let ((labelfn (or labelfn (lambda (item) (format "%s" item))))) > (hierarchy-map > - (hierarchy-labelfn-indent (lambda (item _) (insert (funcall > to-string item) "\n"))) indentation shouldn't be the responsibility of this function. This function is lower-level. Could you please also add a unit test or two for the new function? Thank you for your work -- Damien Cassou "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill