More links - network, afk-prompt and timewarrior export

[tobixen]

aw-watcher-afk-prompt is a fork of the inactive aw-watcher-ask-away, interactively asks the user for information about afk gaps

aw-watcher-network-rs seems to overlap aw-watcher-netstatus. Added information that netstatus is simpler and more stable, while network-watch is more feature-rich.

aw-exporter-timewarrior - a categorization, tagging and exporting tool. Currently exporting to timewarrior, but my intentions is to rename it to aw-tagger with timewarrior as an optional backend.

---

Important

Add new watchers and exporter to watchers.rst, including aw-watcher-afk-prompt, aw-watcher-network-rs, aw-watcher-lid, and aw-exporter-timewarrior.

• Watchers:
  • Adds aw-watcher-afk-prompt for posing questions after AFK periods in watchers.rst.
  • Adds aw-watcher-network-rs as a more feature-rich alternative to aw-watcher-netstatus in watchers.rst.
  • Adds aw-watcher-lid for monitoring laptop lid, suspend, and power-off status in watchers.rst.
• Exporters:
  • Adds aw-exporter-timewarrior for rule-based categorization and tagging, with plans to rename to aw-tagger in watchers.rst.

^{This description was created by for f90a7c6. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to f90a7c6 in 1 minute and 55 seconds. Click for details.

• Reviewed 33 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 6 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/watchers.rst:73

• Draft comment:
  Clarify that 'aw-watcher-afk-prompt' is a fork of the inactive aw-watcher-ask-away. This added context may help users decide which AFK watcher suits their needs.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and does not provide a specific code suggestion or request for clarification on the code itself. It seems to be suggesting an update to documentation or comments, which is not within the scope of the rules for useful comments.

2. src/watchers.rst:79

• Draft comment:
  The updated description for 'aw-watcher-netstatus' is more concise. Consider adding details (e.g. supported platforms) if relevant for clarity.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

3. src/watchers.rst:80

• Draft comment:
  For 'aw-watcher-network-rs', mention that it is implemented in Rust (as the '-rs' suggests) and briefly note what extra features it offers.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

4. src/watchers.rst:82

• Draft comment:
  Rephrase the lid watcher description for consistency. For example, use 'Watches the laptop's lid, suspend, and power-off status' to match other concise bullet points.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

5. src/watchers.rst:90

• Draft comment:
  Reword the timewarrior exporter description for clarity. For example, replace 'an attempt on rule-based categorization' with a clearer statement describing its purpose and future plans.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

6. src/watchers.rst:93

• Draft comment:
  Typographical suggestion: Consider changing "an attempt on rule-based categorization and tagging of activities" to "an attempt at rule-based categorization and tagging of activities".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a minor grammatical correction suggesting "at" instead of "on". While the suggestion is technically correct (idiomatic English uses "attempt at" not "attempt on"), I need to consider the rules. The rules state: "Do NOT comment unless there is clearly a code change required" and "Do NOT make comments that are obvious or unimportant." This is documentation, not code, but the same principle applies. The comment is about a very minor grammatical issue that doesn't affect functionality or clarity significantly. The rules emphasize only commenting when there's a clear code change required, and this is more of a stylistic/grammatical nitpick. However, the rules also say "Comments that suggest code quality refactors are good! But only if they are actionable and clear." This is actionable and clear, but it's not really a code quality issue - it's a minor grammar correction in documentation text. While the grammatical correction is technically correct, this could be considered an "obvious or unimportant" comment per the rules. The meaning is clear either way, and this is a very minor stylistic issue that doesn't significantly impact the documentation quality. The rules explicitly state not to make comments that are "obvious or unimportant," and a minor preposition change in documentation text falls into this category. While grammatically more correct, it's not a significant issue that requires a code change. This comment should be deleted. It's a minor grammatical nitpick that doesn't meet the threshold of being important enough to warrant a review comment. The meaning is clear with either preposition, and this falls under "obvious or unimportant" comments that should be avoided.

Workflow ID: wflow_PANg7ggt8KaaF7Iu

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}