Ability to match category by Editor project? #619

Activity

1. TimeToBuildBob commented on Feb 27, 2026

   

   TimeToBuildBob

   on Feb 27, 2026

   Contributor

   More actions

   Interesting idea. Currently, AW categorization rules match on app and title fields, but there's no built-in concept of "editor project" in the data model.

   How this could work:

   The editor project information is already available in several watchers:

   • aw-watcher-vscode reports the workspace/project name in the event data
   • aw-watcher-vim (via aw-watcher-afk integration) can include the working directory
   • Other editor watchers typically include file path or project name

   The categorization system could be extended to match on arbitrary event data fields, not just app and title. This would enable rules like:

   {
     "name": ["Work", "Project Alpha"],
     "rule": {"type": "regex", "field": "project", "pattern": "project-alpha"}
   }

   Implementation path:

   1. The query language already supports accessing arbitrary event data fields (events[i].data.project)
   2. The categorization UI would need a "field" selector (currently hardcoded to app/title)
   3. A "detect fields" button could scan recent events to discover available fields per bucket type

   This relates to #678 (configurable title attribute) — both are about making the UI aware of custom event fields beyond the hardcoded app/title pair. A generic "match on field X" capability would solve both issues.
2. tobiasdiez commented on May 16, 2026

   

   tobiasdiez

   on May 16, 2026

   More actions

   @TimeToBuildBob please implement this. I field selector in the category ui should be easy to implement. Analyze if there are additional changes needed to the aw server.
3. TimeToBuildBob commented on May 16, 2026

   

   TimeToBuildBob

   on May 16, 2026

   Contributor

   More actions

   I dug through the code before jumping into a patch, and this is not quite the easy UI-only change it first looked like.

   Findings:

   • aw-webui category queries currently run through canonicalEvents(...) in src/queries.ts, which builds categories from currentwindow + browser + stopwatch data.
   • Editor buckets (app.editor.activity) are queried separately via editorActivityQuery(...) and are only used for the editor visualizations (top_files, top_languages, top_projects). They are not part of the category query path today.
   • On the Python stack, the query engine already has a way to restrict regex matching to specific event fields: aw_core.aw_transform.classify.Rule supports select_keys. So for Python aw-server, a field selector itself would not require server changes.
   • On the Rust stack, parity is missing right now: aw-server-rust only parses regex + ignore_case and matches against all string values, so select_keys support would need to be added there separately.

   So the important distinction is:

   • If the target field already exists on the events used by canonicalEvents(...), then exposing select_keys / a field selector in the UI is enough on the Python server.
   • If the target field only exists in editor buckets, then a field selector alone will not fix this issue, because those events never reach the categorization pipeline.

   Given that this issue is specifically about matching by editor project, I don't want to fake-progress it with a UI patch that still won't make activity-watch-mode work. The first design question is whether we want category queries to consume editor bucket data directly, or whether editor-derived fields should somehow be merged onto the window events before categorization.

   If we want, I can take the next step and split this into:

   1. a small aw-webui change for field selection on existing canonical event fields, and
   2. a separate design/implementation issue for editor-bucket-aware categorization.
4. tobiasdiez commented on May 16, 2026

   

   tobiasdiez

   on May 16, 2026

   More actions

   @TimeToBuildBob Do it right, so "a separate design/implementation issue for editor-bucket-aware categorization."
5. TimeToBuildBob commented on May 16, 2026

   

   TimeToBuildBob

   on May 16, 2026

   Contributor

   More actions

   I split this out so the thread stops conflating three different problems:

   • Support selecting explicit event fields in category regex rules #823 tracks exposing explicit field selection in category regex rules (select_keys) for the existing canonical category events.
   • Support select_keys in regex categorization and tagging rules aw-server-rust#604 tracks Rust parity for that feature. Right now the Rust query engine ignores select_keys and still matches every string field, so a webui-only patch would be misleading.
   • Support editor-bucket-aware categorization for editor project/workspace rules activitywatch#1305 tracks the actual editor-bucket-aware categorization design needed for matching editor project / workspace data from activity-watch-mode.

   I’m not pushing a pure aw-webui patch on this issue because it would still not solve the original editor project request, and on the Rust stack it would advertise behavior the backend does not honor yet.

   So the clean split is:

   1. aw-webui#823 + aw-server-rust#604 for field selection on the current categorization pipeline.
   2. activitywatch#1305 for the larger editor-bucket-aware categorization path.

   I’d keep this issue as the user-facing umbrella for the original request and drive the implementation through those scoped follow-ups.