Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maybe a problem with treepy-remove? #9

Open
dsedivec opened this issue Sep 8, 2020 · 1 comment
Open

Maybe a problem with treepy-remove? #9

dsedivec opened this issue Sep 8, 2020 · 1 comment

Comments

@dsedivec
Copy link

dsedivec commented Sep 8, 2020

I'm running into an error using treepy-remove and I don't know why. I feel like it was working until recent Emacs, say 27.1 up through master as of a week or so ago. (Edit: I downloaded 26.3 and tested the below example, and I still get the error on 26.3, so 27.1 doesn't really have anything to do with this. I suspect the reason that things seemed to break when I upgraded to 27.1 is simply that the order of elements in mode-line-misc-info, which is what I'm traversing with treepy, has changed.)

Here's a test script that tries to remove the (c d) list from the middle of the example list:

(require 'treepy)
(require 'pp)
(setq zip (treepy-list-zip '((a b) (c d) (e f))))
(setq second-list-zip (treepy-right (treepy-next zip)))
(message "Here's the node at second-list-zip:")
(pp (treepy-node second-list-zip))
(message "About to do `treepy-remove'")
(setq second-list-removed-zip (treepy-remove second-list-zip))
(message "`treepy-remove' done, will now print")
(pp (treepy-root second-list-removed-zip))

Here's the output when run under Emacs 27.1:

$ /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs --batch -L treepy.el/ -l scratch.el
Here’s the node at second-list-zip:
(c d)

About to do ‘treepy-remove’
Wrong type argument: listp, a

Am I correct that this should work?

The weirdest thing is that I swear this has been working for a long time, and I don't see any changes to treepy, but I have recently upgraded Emacs, so since that's the only relevant change I can think of, I have to assume something changed in Emacs?

FYI:

$ uname -a
Darwin thehost 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 18 20:50:10 PDT 2020; root:xnu-4903.278.43~1/RELEASE_X86_64 x86_64

$ /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs --version
GNU Emacs 27.1
Copyright (C) 2020 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

$ (cd treepy.el; git log -1)
/tmp/treepy.el
commit 3ac940e97f3d03e48ca9d7fcd74916a9b01c72f3
Author: Daniel Barreto <[email protected]>
Date:   Tue Aug 11 13:21:03 2020 +0200

    Ignore `*.elc` files

Thank you for writing this excellent library! I'm using it to edit the various mode line variables, to insert and remove things from them.

@dsedivec
Copy link
Author

dsedivec commented Sep 9, 2020

I did some more research. I'm wondering if maybe these lines in treepy-remove should be deleted?

treepy.el/treepy.el

Lines 400 to 401 in 3ac940e

(while (setq child (and (treepy-branch-p nloc) (treepy-children nloc)))
(setq nloc (treepy-rightmost child)))

As far as I can tell, nloc correctly gets set to the previous node before this point. I'm not sure what this code is trying to do.

Importantly, I don't think it's valid to call treepy-rightmost on child, which is the result of treepy-children? The latter returns the children of the current node, and not a loc as treepy-rightmost expects. I believe that is the source of my error.

When I comment out these two lines and just return nloc as-is, all of the tests in treepy.el-zipper-test.el still seem to pass, and my example from my initial comment works as well.

dsedivec added a commit to dsedivec/dot-emacs-d that referenced this issue Jun 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant