HDD-1725 RTF links

[MalcolmCusack]

Important

Adds LinkElement for RTF links, updates RTF class for link support, and includes minor utility and font updates.

• New Feature:
  • Adds LinkElement class in link.ts to handle RTF links with URL, display text, and external URL flag.
  • Implements getRTFCode() in LinkElement to generate RTF string for hyperlinks.
• RTF Class:
  • Adds writeLink() method in RTF class to add links to documents.
• Utilities:
  • Adds BLUE constant to RGB class in rgb.ts.
  • Updates getRTFSafeText() in rtf-utils.ts to handle non-string inputs.
• Fonts:
  • Adds CALIBRI to Fonts in fonts.ts.
• Misc:
  • Exports LinkElement in index.ts.
  • Bumps version to 0.1.3 in package.json.

^{This description was created by for 6c5c74c. It will automatically update as commits are pushed.}

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to f894fb2 in 2 minutes and 33 seconds

More details

• Looked at 192 lines of code in 7 files
• Skipped 1 files when reviewing.
• Skipped posting 5 drafted comments based on config settings.

1. lib/elements/link.ts:75

• Draft comment:
  In getRTFCode, the external vs non-external branch uses different field formatting (display text vs URL). Confirm if using safeUrl as display text when isExternalURL is false is intended.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The code clearly shows different handling for external vs non-external links. The comment is asking for confirmation of intended behavior, which violates our rules about not asking authors to confirm their intentions. The code and comments suggest this is deliberate design. The class stores both url and displayText, and uses them differently based on isExternalURL flag.
  The different handling could potentially be a bug if the requirements aren't clear. Maybe there's a reason to question this design.
  The code is new and the different handling is clearly documented with comments. If it were a bug, it would be obvious to the author during testing. Asking for confirmation adds no value.
  Delete the comment as it violates the rule about not asking authors to confirm their intentions. The different handling appears intentional and is documented.

2. lib/rtf-utils.ts:21

• Draft comment:
  Additional replaceAll for '~' and line breaks: ensure all necessary RTF special characters are addressed. Confirm that replace order doesn’t conflict.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

3. lib/rtf.ts:56

• Draft comment:
  writeLink() always instantiates LinkElement with the default isExternalURL flag false. Consider exposing this parameter if internal/external link behaviors differ.
• 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%
  The comment makes an assumption about LinkElement's implementation and default parameters that I cannot verify from the shown code. Without seeing LinkElement's implementation, I cannot confirm if internal/external links actually behave differently or if this parameter is important. The comment is speculative without this context.
  I might be too quick to dismiss this - if LinkElement does have this parameter, exposing it could be a valid enhancement. The reviewer might have knowledge of LinkElement's implementation that I don't.
  Even if LinkElement has this parameter, without seeing its implementation or documentation, we can't be certain that exposing it is necessary or useful. The comment is speculative without this context.
  The comment should be deleted because it makes assumptions about LinkElement's implementation that we cannot verify from the available code, making it speculative.

4. package.json:22

• Draft comment:
  The 'async' dependency version (^0.9.2) is quite old. Consider updating it if possible.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

5. lib/rtf-utils.ts:22

• Draft comment:
  On line 22, the escape sequence '\n\r' is used. Typically, Windows-style newlines are represented as '\r\n'. Please verify if this ordering is intentional or if it should be corrected.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_xc46n9VD9lj5KC57

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on ecc2dd6 in 1 minute and 22 seconds

More details

• Looked at 29 lines of code in 2 files
• Skipped 1 files when reviewing.
• Skipped posting 4 drafted comments based on config settings.

1. lib/elements/link.ts:84

• Draft comment:
  Remove or explain the commented-out closing brace (\pard) code if not needed to avoid confusion.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The existing comment on line 82 already explains that "\pard might be needed depending on context." The commented code serves as an example of how to add it if needed. The comment and code together form useful documentation for future maintainers. Asking to remove it could actually reduce the helpfulness of the code.
  The reviewer's comment might have a point about commented code being confusing, as it's generally considered bad practice to leave commented-out code in production.
  In this case, the commented code serves a clear documentation purpose, showing an optional RTF formatting directive that might be needed in certain contexts, with clear explanatory comments.
  The comment should be deleted as the commented code is intentional, well-documented, and serves as useful reference for future RTF formatting needs.

2. lib/rtf.ts:55

• Draft comment:
  Update documentation/comments for the new 'isExternalURL' parameter in writeLink for clarity.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 20% <= threshold 50%
  This comment is asking for an update to documentation or comments for clarity. It doesn't ask for confirmation or testing, but it is purely informative and doesn't provide a specific suggestion or point out a potential issue.

3. lib/elements/link.ts:84

• Draft comment:
  Avoid leaving commented-out code unless it's essential. If the extra closing brace (\pard}) is needed in certain contexts, please document the condition or remove the commented code to improve clarity.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

4. lib/rtf.ts:55

• Draft comment:
  The new 'isExternalURL' parameter is passed to LinkElement. Verify that internal links intentionally use the URL as display text (ignoring the provided displayText) while external links use displayText. Clarify this behavior if needed.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

Workflow ID: wflow_q1LLcQJ2Uj4lMCWv

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 6c5c74c in 1 minute and 36 seconds

More details

• Looked at 19 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 5 drafted comments based on config settings.

1. lib/fonts.ts:4

• Draft comment:
  Remove trailing whitespace from value.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  Trailing whitespace is a minor code style issue. While it's technically correct that there's trailing whitespace, this kind of formatting issue is usually handled automatically by code formatters or linters. It's a very minor issue that doesn't affect functionality.
  The comment is technically correct and trailing whitespace can be considered a code cleanliness issue. Some teams do care about consistent formatting.
  However, this is exactly the kind of minor formatting issue that should be caught by automated tools rather than manual review comments. It's too trivial for a PR comment.
  Delete this comment as it's too minor of an issue and would typically be handled by automated formatting tools.

2. lib/fonts.ts:13

• Draft comment:
  Removed duplicate key 'CALIBARI'; ensure references use 'CALIBRI'.
• Reason this comment was not posted:
  Comment was on unchanged code.

3. lib/fonts.ts:3

• Draft comment:
  Corrected misspelling: 'CALIBRI' replaces the incorrect 'CALIBARI'.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is purely informative, as it only points out a spelling correction without suggesting any changes or improvements. It doesn't ask for confirmation or suggest a specific action to be taken.

4. lib/fonts.ts:4

• Draft comment:
  Remove extra trailing whitespace on the 'COMIC_SANS' line.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  Trailing whitespace is a minor code style issue. While it's technically correct that there's trailing whitespace, this kind of formatting issue is typically handled automatically by code formatters or linters. It doesn't affect functionality and is a very minor concern.
  The comment is technically accurate. Some teams do care about consistent code formatting including trailing whitespace.
  While accurate, this is exactly the kind of minor, obvious issue that should be handled by automated tools rather than PR comments. It adds noise to the review without providing meaningful value.
  Delete this comment as it's too minor and would be better handled by automated formatting tools.

5. lib/fonts.ts:4

• Draft comment:
  The COMIC_SANS property on line 4 has trailing whitespace after the comma. Please remove the extra spaces to maintain clean formatting.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  While the comment is technically correct about the whitespace, trailing whitespace is a very minor formatting issue that should be handled by automated linting/formatting tools rather than manual code review comments. Most IDEs automatically strip trailing whitespace. This kind of comment creates noise without adding value.
  The whitespace could cause git diff noise in future commits. Some teams might have strict formatting standards that care about this.
  Even if formatting is important, this is exactly the kind of thing that should be caught by automated tools like ESLint or Prettier, not manual review comments.
  Delete this comment as it addresses a trivial formatting issue that should be handled by automation rather than manual review.

Workflow ID: wflow_p68jn7218TOPyLgC

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[davemilller]

don't forget to deploy this son of a gun