WakaTime support request

[dupeiran001]

Check for existing issues

• Completed

Describe the feature

WakaTime is a plugin to static coding time of all IDEs together in a dashboard

I'm not sure whether it's possible to support it in zed?

Or support third party plugins?

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[PineappleRind]

this depends on zed-industries/zed#5269
WakaTime has listed a Zed extension as "not yet available" (at the bottom of this page)

[alanhamlett]

A minimal extension API was added in zed-industries/zed#5269, but unfortunately it only supports themes and language extensions so it's not yet possible to build an extension like WakaTime. I've opened an issue to request a full extension API similar to other IDEs:

zed-industries/zed#10795

[gwennlbh]

I'm wondering if a wakatime "LSP" could work, it'd send requests to the server that would run the wakatime-cli.

The documentation on creating editor client plugins mentions running the cli:

• on init: corresponds to initialized
• on file focus change: didOpenTextDocument seems to match
• on file content change: didChangeTextDocument seems to match
• on file save: didSaveTextDocument

So yeah it seems doable, and would even allow easily creating editor plugins for wakatime through LSP, I may start working on this if no one already is '^^

[gwennlbh]

Ok I did create https://github.com/ewen-lbh/wakalsp, I'll try to get sth working by the end of the week

[gwennlbh]

Welp, I should've searched before starting a repo lmao, seems like there's already exactly this: https://github.com/mrnossiom/wakatime-lsp

[guilhermeabel]

I'm gonna try and test this out @ewen-lbh as soon as I can. Nice find

[gwennlbh]

I started a repo for the zed extension, but i'm waiting on mrnossiom/wakatime-ls#2

see https://github.com/ewen-lbh/zed-wakatime

[guilhermeabel]

Great!

[gwennlbh]

I can't really test this on my setup, the file picker dialog never opens so i can't load a dev extension... imma go to sleep anyways it's past 2am in my tz lmao

[gwennlbh]

I have a working PoC! Install instructions on the readme

[volfiros]

I have a working PoC! Install instructions on the readme

I tried your method but it did not work, I was able to install it as a dev extension but coding time is not getting tracked on my dashboard
Btw I am using Linux (fedora)

[gwennlbh]

I have a working PoC! Install instructions on the readme

I tried your method but it did not work, I was able to install it as a dev extension but coding time is not getting tracked on my dashboard
Btw I am using Linux (fedora)

Ooops ._.
Please make an issue on the repo ;)

[bestgopher]

Hi, I published a plugin for wakatime. Please take a try. #1327
You can install it from extensions page:

And set it by .wakatime.cfg or zed settings:

[bestgopher]

A minimal extension API was added in zed-industries/zed#5269, but unfortunately it only supports themes and language extensions so it's not yet possible to build an extension like WakaTime. I've opened an issue to request a full extension API similar to other IDEs:

zed-industries/zed#10795

Hi, here is my repo: https://github.com/bestgopher/wakatime-zed
It works find to me:

[berkus]

@ewen-lbh is this (variation of) your code that has been published? I'm on the phone but still see way too many similarities.

[bestgopher]

@berkus You mean my code is similar with @ewen-lbh 's ? I can responsibly tell you that they have no relation whatsoever. My inspiration came from code-stats. Before I completed this plugin, I was not aware of the existence of this issue.

[berkus]

Okay then, just asking.

[bestgopher]

Okay then, just asking.

Okay

[alanhamlett]

Also the desktop app can track Zed usage, but not detect project only app usage:
https://wakatime.com/desktop

[bestgopher]

Also the desktop app can track Zed usage, but not detect project only app usage:

Hi, @alanhamlett .I recently recommended my plugin to you via email, but you didn’t reply. I’m not sure if you didn’t receive the email, but I’d still like to hear your thoughts.

[alanhamlett]

Nice work both of you! I would like to merge the two into one repo under the WakaTime GitHub Org then give both of you write permission on the repo. First, we should decide what's best... bundling the LSP like @bestgopher or using the external wakatime-lsp like @ewen-lbh. I haven't fully read the whole source code of each plugin yet, are there any other differences?

[bestgopher]

First, we should decide what's best... bundling the LSP like @bestgopher or using the external wakatime-lsp like @ewen-lbh

I don't known which is the best, but for me, I could maintain them by myself. In my opinion, lsp is the part of plugin, it's better to bund them in one repo.

[alanhamlett]

Yes bundling is less error-prone because there's no extra network requests. @bestgopher can you use the official instructions for transferring the repo to alanhamlett GitHub username (because orgs can't receive repos) then I'll transfer it to the WakaTime GitHub org, add you and @ewen-lbh as maintainers, and make it an official plugin on the website.

[bestgopher]

@bestgopher can you use the official instructions for transferring the repo to alanhamlett GitHub username

Done!

[alanhamlett]

@bestgopher I just noticed your version also downloads the LSP server even though it's bundled in the repo. Is that required?
https://github.com/wakatime/zed-wakatime/blob/73ac872be7ebd87df3c409078f1867e1972ce9cb/src/lib.rs#L127

In that case it makes sense to use a shared wakatime-lsp repo like @ewen-lbh does.

[bestgopher]

Is that required?

The Zed extension consists of some WASM files, responsible for providing the startup commands and other initialization tasks for the language server. Currently, there are no other mechanisms for writing Zed extensions. If Zed's extension system is updated in the future, I will synchronize and update the related features accordingly.

[bestgopher]

Is that required?

The Zed extension consists of some WASM files, responsible for providing the startup commands and other initialization tasks for the language server. Currently, there are no other mechanisms for writing Zed extensions. If Zed's extension system is updated in the future, I will synchronize and update the related features accordingly.

[alanhamlett]

So let's re-use the LSP instead of re-writing it, same as @ewen-lbh

[bestgopher]

So let's re-use the LSP instead of re-writing it, same as @ewen-lbh

I don't understand why there is a need to dwell on this. Before developing this plugin, I was not aware of the existence of the wakatime-lsp repository. I briefly looked at its code; its functionality is quite simple and doesn't implement requirements like rate limiting as mentioned in the Wakatime documentation. Furthermore, I don't know if this repository is still being maintained or if it might be deleted in the future. I believe the best solution would be for Wakatime to officially provide a language server. For example, they could develop a wakatime-cli lsp subcommand based on the wakatime-cli tool, which would allow extensions to be developed directly on top of it.

[alanhamlett]

Yes an official wakatime-cli-lsp is the best solution, but in general code reuse means all users get benefits of bugs or improvements instead of having to copy those changes into multiple LSP repos.

[gwennlbh]

Hi all!

First of all, thanks @alanhamlett for the invitation! I'm honored to be named maintainer on a wakatime repo ^^

Then, to clarify things, I don't mind at all the fact that someone else made another repo that does the same thing as mine. I mean this is bound to happen at some point (and I actually did the same before discovering @mrnossiom's wakatime-lsp). I also was pretty busy with other projects and didn't have the time to ask Wakatime for an official repo transfer as the project was not completely finished (it was more of a PoC)

I also think that distributing a common wakatime-lsp would be nice, It'd lower the barrier to entry significantly for wakatime plugin creation, as LSP is really becoming a popular standard that most code editors support nowadays. (I'd even go as far as to say that most wakatime plugins should be rewritten to use a common lsp base, that would be bundled with the cli as @bestgopher mentions, but that's a lot of work for no end-user impact haha)

There's still an issue with (ab)using the LSP standard: since it's made for language support, client extensions often declare a fixed list of languages that should activate the language server. This results in a maintenance burden on client extension implementors for wakatime: they have to maintain a list of all programming languages the editor supports, and as new ones inevitably get added, wakatime is bound to break and not report code stats for a less popular language. This is more of a Zed issue though.

Also @mrnossiom has mentionned buidling wakatime-lsp for Helix initially, maybe the IDE could also receive a repo on the wakatime org? (idk where the plugin is in term of stability)

I've gone ahead and announced this on my own repo, see gwennlbh/zed-wakatime#10. Will archive it sometime around next week

[alanhamlett]

Also @mrnossiom has mentionned buidling wakatime-lsp for Helix initially, maybe the IDE could also receive a repo on the wakatime org? (idk where the plugin is in term of stability)

For visibility, I've reached out to @mrnossiom about that in this comment

[mrnossiom]

Hi Alan, Ewen and bestgopher,

I'd be glad to transfer the repository to the wakatime/* namespace, where it would get more visibility. I have recently not been active on the repository because it works fine as is, but I would be happy to resolve bugs or discuss new features if necessary.

About abusing the LSP standard, I really think the LSP specification has grown enough to become more of a code editor plugin standard. I think IDEs would be kin to enable global LSPs (here's Helix tracking issue helix-editor/helix#9318).
Aside, I've been experimenting another case of LSP abusing for spellchecking (https://github.com/mrnossiom/lspelling)

For extensions in general (and Zed's specifically), using wakatime-lsp as a base is quite good to bootstrap. Maybe it will later evolve into its own program to take advantage of Zed's specific API (like the VS Code extension).

To answer bestgopher concerns on features, my initial idea for wakatime-lsp was to create a thin wrapper around wakatime-cli which actually does most of the network, debounce, heartbeat stuff. It stores heartbeats when offline to send them all when reconnecting. I don't have to rewrite this code which is used by all, and I get to benefit from it.
Furthermore, I had written down some feature ideas as comments in my code, but I actually think these should be discussed at the CLI level to keep all the features at the same place.

Last, about mrnossiom/wakatime-ls#5, after having a friend installing the Zed plugin, I understand that the experience is unclear. I intend to finish Ewen's automatic wakatime-cli downloading. I'll add a flag to disable it for declarative systems.

Tell me Alan when do you want to proceed to transfer the repository

Hope I've answered everyone questions 😄

[gwennlbh]

I think that bundling the lsp part as a subcommand of wakatime-cli would be better, it means less binaries to download and therefore much less work

Now obviously wakatime-cli is in Go, so we wouldn't be able to reuse all that Rust code but I still think it's worth it, and making LSPs in Go is pretty feasible

[mrnossiom]

If Alan prefers to bundle the LSP in the official CLI, it's an option too. The LSP implementation is far from long. I don't know if the added binary weight is visible.