Building an emacs watcher


#1

I would definitely like to see editor plugins; I already started to write one for Emacs based on WakaTimeʼs. Iʼm still thinking how to name the bucket and when to send events, but I hope I can finish it this month.


How ActivityWatch could be better
#2

Awesome! Feel free to share the source code, I’d love test it out when you have a working prototype!
I’m a vim user myself, but I’d love to see how you’ll implement it.

The current convention is “watcher-name_hostname”. The important part is to have the hostname as a suffix so in case you have two watchers reporting to the same aw-server on different hosts, they shouldn’t write to the same bucket due to having the same name. Otherwise you’re technically allowed to have any name you wish.

To add basic support for visualizing code activity in the webui later we could probably reuse the webactivity visualization to start with,


#3
  • The current convention is “watcher-name_hostname”.

Is the hostname part here is where the hostname in the GUI comes from?


#4

Our current create bucket REST API is somewhat ugly sadly. Take a look at http://127.0.0.1:5600/api/#!/default/post_bucket_resource and you can see that you need to supply the bucket_id path for the post request which should be “client-name_hostname” but then you also need to specify the “client” and “hostname” separately inside the payload.

Ideally you should have to only pass the payload including “client” and “hostname” and then let aw-server create the “client-name_hostname” string itself, but that’s sadly not the case currently. We should probably fix that as well as a couple other stupid designs of the REST API in some later aw-server version.


#5

Ah, itʼs much clearer now.

[…] bucket_id path for the post request which should be “client-name_hostname”

If it should be and not must be, itʼs not a problem. Also, I can simply go with a bucket name of “emacs” or even “editor”. Or are buckets shared between hosts? Based on your second paragraph I guess they are, but that might not be a problem; I mean, why is it a problem if both two machines of mine report to the same bucket?


#6

Not really a problem no, but it is ugly API design IMO since you are now supposed to specifying two fields twice.

It’s just that you’re not losing anything from saving which host the activity was on. Currently in the webui we show activity reports for each host, but this allows us to later on add the ability to both show activity by host and a sum of all hosts together.


#7

you are now supposed to specifying two fields twice.

Why am I? That is only because you suggest to name buckets like this. If it is saved anyway from the JSON, the bucket name suggestion can be changed, and there you have it. Or am I missing something?


#8

You can use whichever bucket id you want. {clientname}_{hostname} is just an old convention (not a must) that some bucket-specific visualization stuff in the web UI (specifically the window and AFK buckets) depends on for now (but shouldn’t in the future, see this issue).

You could call it whatever you want (like editor or emacs as you suggested) and just specify the hostname in the POST parameters.

tl;dr: You are not missing anything :slight_smile:

I mean, why is it a problem if both two machines of mine report to the same bucket?

We haven’t gotten sync figured out quite yet, but it complicates matters a lot if several hosts are able to write to the same bucket. It would also mess up how heartbeats work. As such, a bucket must not have more than one producer (a producer being uniquely identified by a (client_type, host) pair).


#9

Donʼt heartbeat events contain the client and hostname, too? Because if they do, you can use that to pair events with corresponding heartbeats. This might become a big deal with editor plugins where multiple files can be open, so all of them might send a heartbeat (except if you want to depend on editor plugin writers to send only the active ones, like in the case of WakaTime).


#10

You could add that obviously, but since we have already decided to have host specific buckets this is not the case. The aw-webui also currently uses the bucket hostname to identify which buckets to match, so it would be pretty annoying to have a corner case for this watcher.

This gives the exact same functionality anyway. Our database is also optimized to fetch events from a bucket so this would make it much slower in the case where you only want events from a specific host (the “data” field is just a string, would have to go through that data manually).

It would be preferable to only send the active ones.

We had a similar scenario when developing aw-watcher-window where the most important functionality was to send the focused window but we also considered sending which other windows were open in the background. We decided to have one bucket with the eventtype “currentwindow” which contains the focused window and then considered having a separate bucket with the eventtype “allwindows” or something like that, but then realized that there’s little use of tracking windows which the user doesn’t use. After all, what’s interesting with activitywatch data is what programs you are using the most, what programs are running but you are not using are generally not very interesting data.


#11

I agree, but in this case if I want to see “what projects did I work on today on all my machines?”, then I must know what machines I used today, so I can merge the corresponding buckets (at least visually), which is exactly the use case of WakaTime and similar services, to which AW is an alternative (at least as advertised). Hence my suggestion to use one bucket for this task.) Also, AFK will most probably true on machine A when Iʼm using machine B; but Iʼm not actually AFK, but BaDK (Behind a Different Keyboard).

OTOH, using the same bucket for tracking active windows on each hosts may not be a good idea, as when I use two computers simultaneously, I will have two active windows (which looks silly).


#12

Even if you did this, as @ErikBjare said you will break the heartbeat API completely if you send heartbeats from two instances of your watcher into the same bucket since they have different states.
It will be much easier to just do a query where merge together all buckets as a summary across all hosts in the webui rather than rewrite and break the heartbeat API.


#13

Long time since the last activity here, but just wanted to mention that we now have the aw-watcher-vim and aw-watcher-vscode watchers which work well and have visualization support in aw-webui. If you are still working on this and looking for reference implementations those are great places to start looking :slight_smile: Just look at the event format we have in those watchers and use the same buckettype (“app.editor.activity” if I remember correctly) and it should show up!


#14

Please ping me if/when we have an emacs watcher. I’d love this feature.