feat: add 2 new high level inspector command

[nhannht]

• inspector-inspect-defun act like M-x with trigger inspector on result
• inspector-inspect-region act like eval-region with trigger inspector on result Motivate: modern code environment with high-level languages like Python or Clojure will support some kind of data inspector. But Emacs/Elisp util now still does not have proper support for this kind of function. In my experience, when I developed 1 package that fetches a somewhat complicate JSON and convert it to an Elisp object. It is a nightmare to read the result. So I hope this package and the high-level commands it supports will help me solve this problem.

We already have inspector-inspect-last-exp which acts like C-x C-e, I think 2 new commands (actually 4 because 2 others in tree-inspector.el) will be useful

Showcase

https://user-images.githubusercontent.com/69144096/217055602-91205c20-48a1-4301-ba18-89dabfef625d.mp4

https://user-images.githubusercontent.com/69144096/217055668-e8bb692e-175b-4fe3-bc6a-23b2848104f0.mp4

[nhannht]

I think we have a problem with git here. Why are old commits still showing here? My source code on the local machine doesn't show any problem. You should look into this issue to ensure there is no mess in the git history.

[mmontone]

I think we have a problem with git here. Why are old commits still showing here? My source code on the local machine doesn't show any problem. You should look into this issue to ensure there is no mess in the git history.

It may be that I squashed and commit, that is a valid thing to do :man_shrugging: .

Can you try first getting your master branch up to date with my master branch, then rebase your feature branch on master branch. Then merge with fast-forward over master and try pull request.

[mmontone]

First copy your work somewhere safe, so that you don't lose it with git commands. If you can make things work, then great. If you don't, then perhaps I can apply your changes manually.

[nhannht]

Can you manually apply my changes, I will close this PR. It may be that I squashed and commit, that is a valid thing to do

I saw the problem, and I think that actions may be valid when working on the project alone, but if we start to work with someone else, there is a BUG here that needs to be addressed. Going forward, I hope you can state what you want in terms of PRs (e.g., squash or amend, etc.) instead of rewriting your repo history. From what I understand, Github will not auto-rewrite the fork history even with sync fork action. This would create many issues, so I will fix the branch later and may remove the latest commit as I can only squash/amend the latest commits.

[mmontone]

I've applied your patches. But the tests failed now. Do you see the problem?

[mmontone]

I think I messed up the yaml. Will try to fix.

[mmontone]

It is good again. Please review if I did something wrong in the merge.

[nhannht]

Thank you, the best solution for me the next time is to delete my fork and create a new one.
This link state that

Deleting a fork will not affect contributions to the original repository. Any contributions made to the original repository will remain intact, regardless of whether or not the fork exists.

[mmontone]

Thank you, the best solution for me the next time is to delete my fork and create a new one. This link state that

Deleting a fork will not affect contributions to the original repository. Any contributions made to the original repository will remain intact, regardless of whether or not the fork exists.

That's very odd. I didn't know this could happen when using squash + merge.