Request for a how-to-debug section in the readme

[DivineDominion]

This looks great, so I tried the package :)

I mostly have Swift code lying around, so I fired up eglot/tree-sitter-mode/codemetrics in Emacs 28.2.

The annotations in the buffer look very tasty -- but I couldn't get the % to increase e.g. here:

It's likely because the function itself returns a closure, and so it appears to 'exit early'. But all the complexity is inside the returned closure. That's my guess because this works:

It'd be great if you could add a getting started section to the README to help folks like me troubleshoot this and e.g. inspect the data codemetrics returns. 🙏

[jcs090218]

I agreed. I will find some time and update the README. Thanks for the advice! 👍

Here is the short answer for debugging,

1. (setq codemetrics--show-log t) to see more logs (weather is is useful or not)
2. M-x codemetrics-debug-mode, it will show depth and score instead of the result (overlays, must use with codemetrics-mode)
3. Use these functions to see the data codemetrics returns:

• codemetrics-buffer
• codemetrics-region
• codemetrics-analyze

You can use it this way:

(defun my-print-codemetrics-data ()
  "..."
  (interactive)
  (message "%s" (codemetrics-region)))

Then M-x my-print-codemetrics-data the function.

[konrad1977]

Does it matter which version of tree-sitter we are using? I am also using Swift but I could only see the overlay in one of my files. I am using this parser for Swift. Its much faster than the Alex Pinkus version https://gitlab.com/woolsweater/tree-sitter-swifter

[konrad1977]

I got so inspired by your package @jcs090218 so I wrote something like this but for references in code.

[jcs090218]

Does it matter which version of tree-sitter we are using? I am also using Swift but I could only see the overlay in one of my files. I am using this parser for Swift. Its much faster than the Alex Pinkus version https://gitlab.com/woolsweater/tree-sitter-swifter

This package uses tree-sitter.el, so it uses whatever the parser in the upstream package tree-sitter-langs. Someone just opened a thread here so you can build your own parser, see emacs-tree-sitter/tree-sitter-langs#180. :D

I got so inspired by your package @jcs090218 so I wrote something like this but for references in code.

That's so cool! Are you planning to publish as a package? Can't wait to see this in Emacs! 😄

[konrad1977]

I have a POC version here. Feel free to report bugs. After looking in your code I know that you way more fluent in Elisp than I am. So feel free to suggest changes.
I tried to add some basic findings of variables in local file. I really need to ironing out bugs.

Source Code:
https://github.com/konrad1977/emacs/blob/main/localpackages/overlay-usage.el

[jcs090218]

Thanks for sharing! 🚀 ❤️

I might create another package for this, fake-ref-mode, local-ref-mode, etc. It looks very cool! :D

TBH, I am not very good with Swift, so feel free to debug and change the rule sets for your favorite languages. 😅

[konrad1977]

I am using regex only, tree-sitter would be much more accurate. But it only knows about the current structure, correct? We need LSP support to actually understand that one symbol belongs to the correct object.

What will fake-ref-mode, local-ref-mode do?

[jcs090218]

It depends on how you create the tool. If we are using tree-sitter, parsing the whole project wouldn't be an issue (it still depends on your project size, time complexity is O(n)). Then we can create IDE like experience (not LSP). For LSP implementation, we can see Emacs Elsa's elsa-lsp.el.

My intention here is to bring up the idea, and this idea is definitely possible.