From: Damien Cassou <damien@cassou.me>
To: mousebot <mousebot@riseup.net>, emacs-devel@gnu.org
Subject: Re: hierarchy-print doesn't allow sending indent-string arg to hierarchy-map
Date: Sun, 30 Jul 2023 08:16:20 +0200 [thread overview]
Message-ID: <87jzuh2abv.fsf@cassou.me> (raw)
In-Reply-To: <a0e432e5-c9b3-1a98-567e-8cb0d8243922@riseup.net>
Hi,
mousebot <mousebot@riseup.net> writes:
> My initial query was also a way of asking if there is any (other) way
> in hierarchy.el of printing while respecting indentation.
I think `hierarchy-print' is what you need. As you can see, the
implementation is very short so you can also copy/paste/adapt the code
of the function to your needs.
> I'm unsure as to how to refactor hierarchy-print, as I don't
> understand what you think it ought to do differently once
> hierarchy-print-line is added.
The goal is to have hierarchy-print keep its current behavior but
leverage `hierarchy-print-line' for its implementation. I have something
like this in mind (not tested):
(defun hierarchy-print (hierarchy &optional to-string)
"Insert HIERARCHY in current buffer as plain text.
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\"."
(hierarchy-print-line
hierarchy
(hierarchy-labelfn-indent
(lambda (item _) (insert (funcall to-string item) "\n")))))
> I also wonder if it's perhaps a little confusing to have an arg
> 'to-string' that is now likely to be a call to
> `hierarchy-labelfn-indent`, whereas in `hierarchy-print` `to-string`
> is a function handed to hierarchy-labelfn-indent as an argument.
hierarchy has a notion of "labeling function" (parameters of this type
are called LABELFN). A labeling function is one that takes an item
object and an indentation level number as arguments and returns a
string. The `hierarchy-labelfn-indent' function takes a "labeling
function" as argument and returns another one.
The function that `hierarchy-print' takes as parameter is called
TO-STRING instead of LABELFN because it only accepts an item object as
argument.
> In that case, perhaps -print-line should have the same call to
> `hierarchy-labelfn-indent` in its body, so that the to-string arg is
> of a similar form to -print?
I disagree. In `hierarchy-print-line', the second parameter should be
named LABELFN instead of TO-STRING (sorry for not saying that
earlier). The docstring should say that the function is not responsible
for indentation and that the user is free to call
`hierarchy-labelfn-indent' or `hierarchy-print' if s/he cares about
indentation.
> Finally, is there anything wrong with simply making the indent arg in
> the lambda in my original suggestion '&optional'?
>
> i.e.
>
> (defun hierarchy-print (hierarchy &optional to-string indent-string)
> (let ((to-string (or to-string (lambda (item) (format "%s" item)))))
> (hierarchy-map
> (hierarchy-labelfn-indent (lambda (item &optional indent)
> (insert (funcall to-string item indent) "\n"))
> indent-string)
> hierarchy)))
The problem is not this lambda as `hierarchy-labelfn-indent' will always
call it with 2 arguments anyway. The problem is with the TO-STRING
parameter which used to be called with 1 argument but now requires
2. For example, the code below works before the change you suggest but
triggers an error after:
(hierarchy-print hierarchy (lambda (item) (format "-%s-")))
This is because the lambda here will now be called with 2 arguments but
it only declares 1 parameter.
To go in the direction you suggest, we could use `func-arity' on
TO-STRING to detect how many arguments we have to pass and then call it
with either both ITEM and INDENT or only with ITEM.
> Maybe sending 'nil' as an argument to funcall is bad news?
it's not the problem
> I don't really understand why the -print function shouldn't take an
> indent-string argument, but it's your pkg not mine.
this is not the problem either. The problem is passing this argument to
TO-STRING. I hope the above would have make this clearer.
--
Damien Cassou
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
next prev parent reply other threads:[~2023-07-30 6:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 16:16 hierarchy-print doesn't allow sending indent-string arg to hierarchy-map Damien Cassou
2023-07-29 13:33 ` mousebot
2023-07-30 6:16 ` Damien Cassou [this message]
2023-08-01 11:11 ` mousebot
2023-08-02 15:48 ` Damien Cassou
-- strict thread matches above, loose matches on Subject: below --
2023-07-12 13:43 mousebot
2023-07-13 3:38 ` Michael Heerdegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jzuh2abv.fsf@cassou.me \
--to=damien@cassou.me \
--cc=emacs-devel@gnu.org \
--cc=mousebot@riseup.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).