unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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



  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).