mmontone / emacs-inspector

Inspection tool for Emacs Lisp objects.
GNU General Public License v3.0
107 stars 9 forks source link

feat: add evil keymap and helping header #18

Closed nhannht closed 1 year ago

nhannht commented 1 year ago

feat: add evil-key-binding

fix: fix most of the previous text (by me) in tree-inspector.el, the logic is wrong even all the test pass, also make tree-inspector-inspect function produce fix buffer string name "tree-inspector" instead of dynamic name (hard to capture and debug)

The previous version didn't support using the "evil key", just like pressing "q" in evil-mode did not work as expected, so I added evil-key-binding. Next, I realized that the tests in tree-inspector-tests.el (not inspector-tests.el) went wrong even though all the tests passed, due to the use of the external treeview package and dynamic buffer string generated by tree-inspector-inspect. So, I fixed them. I also made the tree-inspector function use the fixed string tree-inspector in the popup buffer name instead of a dynamic name. I'm not sure why the dynamic name was used,

(let ((buffer (get-buffer-create
                 (format "*tree-inspector: %s*"
                         (tree-inspector--print-object data)))))

but it does not benefit the package and makes it harder to capture the buffer for testing purposes.

image

mmontone commented 1 year ago

Hi.

I like the idea of the helping header. But I would toggle them using a customization variable instead of via hooks. I can have a look at that.

About the evil bindings, I'd prefer to move them outside the main inspector packages. The inspectors work fine without evil mode. Is it possible to move evil stuff to inspector-evil.el for example?

nhannht commented 1 year ago

I like your idea. The problem we are discussing here is how to manage our code, correct? For example, take the helm package. Any file in this repository is more than 100 lines of code (LOC). That is why separating them is the smart move.

The code I added is just a few, relatively unimportant lines. That is why I didn't decide to create a new file. However, if that is your opinion, I will refactor it. The idea that the "header" should appear or not based on user configuration is correct. I will add some improvements.

mmontone commented 1 year ago

Yes, do that please.

About the evil stuff, if it is just a couple lines of code I think another option would be to include as a "recipe" in the readme, that the user can copy and paste if he uses evil-mode. The more that can be done from the outside the better IMO.

nhannht commented 1 year ago
mmontone commented 1 year ago
  • I change my mind and think that the header function is not necessary, so I removed it.

As you wish. I kindof liked it, though. Perhaps turned-off by default, I don't know.

mmontone commented 1 year ago

I merged your changes, except the evil-map binding for q. Just use normal kill-buffer command. Hope you are Ok with that.