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

Issue with symbolic links #1157

Closed
joao8545 opened this issue Jan 7, 2025 · 1 comment
Closed

Issue with symbolic links #1157

joao8545 opened this issue Jan 7, 2025 · 1 comment
Labels
bug Something isn't working triage

Comments

@joao8545
Copy link

joao8545 commented Jan 7, 2025

I use dotbot to manage my config files. It basically create symbolic links from my dotfiles directory (~/.dotfiles) to wherever the file should go. Today when inspecting how was my progress in setting up some configs for neovim I realized there was an issue with some of the heartbeats. The file being reported is the destination path and not the place of the original file. Even though I am running neovim from my dotfiles directory and neovim reports the file paths as being from the dotfiles directory, I get shown in the logs a file from ~/.config directory.
This issue probably appeared recently, as I havent changed my workflow nor the config file wakatime and I have 'valid' heartbeats from yesterday.

Environment:

  • OS: linux
  • Platform: amd64

Logs:

{"level":"debug","now":"2025-01-07T01:34:17+01:00","caller":"project/project.go:249","func":"github.com/wakatime/wakatime-cli/pkg/project.Detect","message":"execute project-file-detector","version":"v1.110.0","os/arch":"linux/amd64","file":"/home/joao/.config/nvim/lua/plugins/todo.txt","time":1736209956,"plugin":"neovim/801 vim-wakatime/11.3.0","lineno":16}

swappy-20250107_015009
(output of :lua print(vim.api.nvim_buf_get_name(0)))

@joao8545 joao8545 added the bug Something isn't working label Jan 7, 2025
@github-actions github-actions bot added the triage label Jan 7, 2025
@joao8545
Copy link
Author

Upon further inspection this was caused by the way that expand("%:p") and print(vim.api.nvim_buf_get_name(0)) differs. So the underlying issue is at the plugin level. I will close this issue and move it to the plugin repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage
Projects
None yet
Development

No branches or pull requests

1 participant