Add support for Text fragment feature (#1545) by thiru-appitap · Pull Request #1600 · lycheeverse/lychee

thiru-appitap · 2024-12-25T08:15:03Z

Text Fragment feature implementation pull request. The feature follows the published URL Fragment Text Directives specification (https://wicg.github.io/scroll-to-text-fragment/).

lychee -vv --include-text-fragments  https://developer.mozilla.org/en-US/docs/Web/URI/Fragment/Text_fragments

[DEBUG] tdirective: "text=From%20the%20foregoing%20remarks%20we%20may%20gather%20an%20idea%20of%20the%20importance
[DEBUG] status: Completed
[DEBUG] result: "From the foregoing remarks we may gather an idea of the importance"
[200] https://mdn.github.io/css-examples/target-text/index.html#:~:text=From%20the%20foregoing%20remarks%20we%20may%20gather%20an%20idea%20of%20the%20importance
[DEBUG] tdirective: "text=linked%20URL,-'s%20format"
[DEBUG] status: Completed
[DEBUG] result: "linked URL"
[DEBUG] tdirective: "text=Deprecated-,attributes,attribute"
[DEBUG] status: Completed
[DEBUG] result: "attributes     charset Deprecated   Hinted at the character encoding of the linked URL.   Note:This attribute"
[200] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#:~:text=linked%20URL,-'s%20format&text=Deprecated-,attributes,attribute
[DEBUG] tdirective: "text=downgrade:-,The%20Referer,be%20sent,-to%20origins"
[DEBUG] status: Completed
[DEBUG] result: "The Referer header will not be sent"
[200] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#:~:text=downgrade:-,The%20Referer,be%20sent,-to%20origins
[DEBUG] tdirective: "text=linked%20URL,defining%20a%20value"
[DEBUG] status: Completed
[DEBUG] result: "linked URL as a download. Can be used with or without a filename value:    Without a value, the browser will suggest a filename/extension, generated from various sources:   The Content-Disposition HTTP header  The final segment in the URL path  The media type (from the Content-Type header, the start of a data: URL, or Blob.type for a blob: URL)     filename: defining a value"
[200] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#:~:text=linked%20URL,defining%20a%20value

If the fragment directive is not found, a TextDirectiveNotFound error will be returned.

Below changes are completed:

Fragment Directive parser uses fancy-regex

this package was added as a dependency

a new flag, include-text-fragments is added to support the feature

this is a deviation from the original feature request (which asked for using the text-fragments flag itself)

Fragment (Text) Directive feature is tested on LTR sites only
new UrlExt trait is implemented to enhance Url's to support Fragment Directive
Support for multiple text fragment directives (for example, #:~:text=linked%20URL,-'s%20format&text=Deprecated-,attributes,attribute)
tests are added for validating the feature
cargo clippy & cargo tests were executed

thiru-appitap · 2024-12-25T09:09:00Z

I missed to run the clippy across the test modules - the related lint failure issues are now fixed and ready for review!

mre · 2024-12-25T11:24:31Z

lychee-lib/src/utils/url.rs

+        );
+        match url {
+            Ok(url) => {
+                eprintln!(


This could be an assertion

Modified the tests to have asserts (instead of the manual checks that was earlier)

mre · 2025-01-10T13:47:09Z

lychee-lib/src/checker/website.rs

+                let mut status = Status::new(&response, self.accepted.clone());
+                if self.validate_text_fragments && has_fragment_directive {
+                    if let Ok(res) = response.text().await {
+                        info!("checking fragment directive...");
+                        if let Some(fd) = req_url.fragment_directive() {
+                            info!("directive: {:?}", fd.text_directives);
+                            match fd.check(&res) {
+                                Ok(stat) => {
+                                    status = stat;
+                                }
+                                Err(e) => {
+                                    return e.into();
+                                }
+                            }
+                        }
+                    }
+                }
+                status


Maybe we can move that into a function/method?

some tests for that part would also be nice

the code is modified to move this into a separate function - as well, bulk of the logic is abstracted at the textfrag crate itself so that the websitechecker will deal with only error responses from the text fragment checker function.

mre · 2025-01-10T13:47:53Z

lychee-lib/src/client.rs

+        assert!(res.status().is_success());
+
+        // start with suffix
+        println!("\ntesting start with suffix...");


you'll probably remove the println!s right?

yes - the println's are removed now

mre · 2025-01-10T13:48:47Z

lychee-lib/src/extract/html/fragdirtok.rs

+
+use crate::types::TextDirective;
+
+const BLOCK_ELEMENTS: &[&str] = &[


This is a long list. Does that mean we'd have to maintain the HTML keywords here? Maybe we can avoid that as it would be an uphill battle.

I am yet to explore alternative approach to this and am open for suggestion - for now, this list is retained (reserving this change for a near future commit)

mre · 2025-01-10T13:50:24Z

lychee-lib/src/extract/html/fragdirtok.rs

I like that this functionality is isolated in its own module. But it's a looot of code. 😅 Not sure what to do here, but at least the ratio of code/tests could be improved.

Perhaps we could move it into a separate crate or use an upstream crate for that? I think it would be a nice library to maintain individually as more applications could profit from it

text fragment is now moved into its own crate, textfrag, in the lychee main tree itself - as I am new to the ecosystem, I'll need help in moving this into a separate crate - please suggest!

mre · 2025-01-10T13:50:54Z

lychee-lib/src/extract/html/fragdirtok.rs

+        let mut all_directives_found = false;
+        let directive = td.directive.borrow();
+
+        'directive_loop: while !all_directives_found {


The labels make it quite hard to read. Have you considered any alternatives?

yes - the code logic was cumbersome and I've rewritten this now - please share your comments!

mre · 2025-01-10T13:53:19Z

lychee-lib/src/types/text_fragment.rs

+pub(crate) const FRAGMENT_DIRECTIVE_DELIMITER: &str = ":~:";
+pub(crate) const TEXT_DIRECTIVE_DELIMITER: &str = "text=";
+
+pub(crate) const TEXT_DIRECTIVE_REGEX: &str = r"(?s)^text=(?:\s*(?P<prefix>[^,&-]*)-\s*[,$]?\s*)?(?:\s*(?P<start>[^-&,]*)\s*)(?:\s*,\s*(?P<end>[^,&-]*)\s*)?(?:\s*,\s*-(?P<suffix>[^,&-]*)\s*)?$";


Where does that regex come from? Did you write it yourself? If there's an "official" regex for those text fragments, we could perhaps add a link to the reference.

this regex was built by myself - I started searching for any equivalent but couldn't land on one when I started this implementation - I am open to revisit this.

In fact, i want to replace regex with a simple parser for this requirement - the specification is not particular about the order of the directives, whereas the regex assumes the order imperatively - with a parser, we might be able to get away from the ordering constraints.

mre · 2025-01-10T13:54:17Z

lychee-lib/src/utils/url.rs

 }

+/// Fragment Directive feature trait
+/// we will use the extension trait pattern to extend the Url to support Text Fragment feature


Thank you - this has now moved into textfrag crate

mre · 2025-01-10T13:55:12Z

lychee-lib/src/utils/url.rs

 }

+/// Fragment Directive feature trait
+/// we will use the extension trait pattern to extend the Url to support Text Fragment feature


Suggested change

/// we will use the extension trait pattern to extend the Url to support Text Fragment feature

/// We will use the extension trait pattern to extend [`url::Url`] to support the text fragment feature

Incorporated this comment in to the textfrag::utils::url file

mre · 2025-01-10T13:55:55Z

lychee-lib/src/utils/url.rs

+/// Fragment Directive feature trait
+/// we will use the extension trait pattern to extend the Url to support Text Fragment feature
+pub(crate) trait UrlExt {
+    /// Checks if the url has a fragment and if the fragment is has the fragment directive delimiter embedded


Suggested change

/// Checks if the url has a fragment and if the fragment is has the fragment directive delimiter embedded

/// Checks if the url has a fragment and if the fragment has the fragment directive delimiter embedded

Updated the comments section (with slight rewording) in the textfrag crate

mre · 2025-01-10T13:56:27Z

lychee-lib/src/utils/url.rs

+}
+
+impl UrlExt for Url {
+    /// Returns whether the URL has fragment directive or not


Suggested change

/// Returns whether the URL has fragment directive or not

/// Checks whether the URL has fragment directive or not

Have addressed this is in the textfrag::utils::url[:16]

mre

Left some comments. I like the overall structure. Good work so far!

thiru-appitap · 2025-01-12T21:45:25Z

Left some comments. I like the overall structure. Good work so far!

@mre
I'll take a look at each of the comments and work to address it - thank you!

mre · 2025-02-05T09:26:33Z

@thiru, any updates? Let me know in case you need any help. 😃

thiru-appitap · 2025-02-05T22:05:09Z

@thiru, any updates? Let me know in case you need any help. 😃

@mre, I will submit the fixes by this weekend for your review. Earlier I started moving the feature into a separate crate, while addressing your review comments, but got pulled into few other tasks and so couldn't get back earlier :-(.

mre · 2025-02-06T01:36:50Z

Thanks, sounds good!

thiru-appitap · 2025-02-12T23:34:54Z

Thanks, sounds good!

@mre my apologies for the delay - while refactoring, into a separate crate, I encountered few corner case issues and it took more time than planned - running the tests now and hoping to re-raise the pull-request by tomorrow!

thiru-appitap · 2025-02-14T04:15:27Z

I am committing the changes into my fork and will initiate a pull-request shortly!

lib's website checker continues to have the logic to validate text fragments clean-up of the tests were done review feedback incorporated - addressed structural, logic, tests and document comments

thiru-appitap · 2025-02-14T04:23:07Z

@mre request your help in addressing the CI / publish-check failure - please recommend if I've to make any changes on my end - thank you!

mre · 2025-02-14T20:42:12Z

lychee-lib/src/checker/website.rs


+    fn check_text_fragments(site_data: &str, url: &Url, mut status: Status) -> Status {
+        let res = check_text_fragments(site_data, url);
+        if res.is_err() {


You don't need the if condition here. You're matching on res.err() below, and in the case where res.err() is not set, it will be None. This case is already covered in your _res match arm since _res is just a placeholder, which also includes the value being None.

Yes - I've updated the code

mre · 2025-02-14T21:16:41Z

textfrag/src/types/status.rs

@@ -0,0 +1,78 @@
+/// Defines the status of the Text Fragment search and extraction/search operation status


Suggested change

/// Defines the status of the Text Fragment search and extraction/search operation status

//! Defines the status of the Text Fragment search and extraction/search operation status

refactored code takes are of this now!

mre · 2025-02-14T21:17:19Z

textfrag/src/types/url.rs

+
+use crate::types::{FragmentDirective, FRAGMENT_DIRECTIVE_DELIMITER};
+
+/// Fragment Directive feature trait


Suggested change

/// Fragment Directive feature trait

/// Fragment Directive extension trait

updated the comment

mre · 2025-02-14T21:18:16Z

textfrag/src/utils/mod.rs

Maybe we don't need that file and can move the code closer to where it's used? (Assuming it's only used in one place.)

removed the folder as part of the refactoring exercise

mre · 2025-02-14T21:20:41Z

textfrag/src/extract/fragdirtok.rs

This module is so large, I'd assume a relatively large doc-block as well.
In there, I'd answer a few questions:

What does the module do?

How is it supposed to be used (including an example)?

What were the design tradeoffs?

What are the possible error conditions?

working on it - will commit this documentation for review!

mre · 2025-02-14T21:23:51Z

textfrag/src/extract/fragdirtok.rs

+
+use crate::types::{TextDirective, TextDirectiveKind, TextDirectiveStatus};
+
+const BLOCK_ELEMENTS: &[&str] = &[


I'm still not too happy that we have to maintain this list.
Looked around for alternatives, and I found https://github.com/servo/html5ever/blob/main/html5ever/src/tree_builder/tag_sets.rs.
Not sure if it can be used, but I wanted to mention it.
If it's too much hassle to integrate, we can keep the current implementation.

unfortunately, the html5ever does not expose these macros for us to consume and so couldn't use it - i don't want to keep a copy of this file inside lychee repository and so ruling it out. And i did search around to check on alternative approaches and found either we need to have a headless browser to manage/identify the element type (as block) or stay with this current approach.
My recommendation, for now, is to keep this code - in future, if the html5ever makes these macros as public, we can potentially be freed up of maintaining this list.

mre · 2025-02-14T21:32:05Z

I've added a few more comments.
Most of them are minor. I think it should be fairly easy to go through them and accept/reject my suggestions from the GitHub UI.

As for the error, it's currently failing because there is no textfrag crate on crates.io. That is to be expected, because we haven't published it yet. However, the question is if we do want to publish it at all.
cargo expects all dependencies to be published on crates.io. We have three options:

Publish the crate under lychee-textfrag. This would require renaming the crate to fit our naming scheme.
Publish the crate as a separate project, e.g. textfrag. Then we'd have to move the code out into a separate repo and perhaps add a CI/CD process for releases. We could keep it in the lycheeverse namespace, or you publish it under your own name. The license has to be compatible (Apache/MIT).
Don't publish the crate. In that case, we'd have to move the textfrag crate as a submodule into the lychee-lib crate. The advantage is that we don't have to set up a separate repo, which will make future changes easier.

I'd vote for option 3, which is the easiest right now and allows us to keep maintaining the code inside lychee. It's still reasonably well encapsuled in its own module and we can always make it a separate crate later once the code is mature enough. The downside is longer compile-times because it would be in the same codegen unit as the rest of the library code.

Detailed instructions for option 3

To merge the textfrag code directly into lychee-lib, here's what you could do:

Move the textfrag code into lychee-lib, perhaps in a submodule like lychee-lib/src/textfrag/
Remove textfrag from your workspace members in the root Cargo.toml
Update any imports in lychee-lib to reference the new module location instead of the external crate

This approach has several benefits:

Simplifies your publishing process - no need to maintain and publish a separate crate
Makes it clear that this is internal implementation code
Gives you more flexibility to change the code without worrying about breaking other potential users

Let me know what you think.

thiru-appitap · 2025-02-15T01:49:34Z

I've added a few more comments. Most of them are minor. I think it should be fairly easy to go through them and accept/reject my suggestions from the GitHub UI.

As for the error, it's currently failing because there is no textfrag crate on crates.io. That is to be expected, because we haven't published it yet. However, the question is if we do want to publish it at all. cargo expects all dependencies to be published on crates.io. We have three options:

Publish the crate under lychee-textfrag. This would require renaming the crate to fit our naming scheme.

Publish the crate as a separate project, e.g. textfrag. Then we'd have to move the code out into a separate repo and perhaps add a CI/CD process for releases. We could keep it in the lycheeverse namespace, or you publish it under your own name. The license has to be compatible (Apache/MIT).

Don't publish the crate. In that case, we'd have to move the textfrag crate as a submodule into the lychee-lib crate. The advantage is that we don't have to set up a separate repo, which will make future changes easier.

I'd vote for option 3, which is the easiest right now and allows us to keep maintaining the code inside lychee. It's still reasonably well encapsuled in its own module and we can always make it a separate crate later once the code is mature enough. The downside is longer compile-times because it would be in the same codegen unit as the rest of the library code.

Detailed instructions for option 3
To merge the textfrag code directly into lychee-lib, here's what you could do:

Move the textfrag code into lychee-lib, perhaps in a submodule like lychee-lib/src/textfrag/

Remove textfrag from your workspace members in the root Cargo.toml

Update any imports in lychee-lib to reference the new module location instead of the external crate

This approach has several benefits:

Simplifies your publishing process - no need to maintain and publish a separate crate

Makes it clear that this is internal implementation code

Gives you more flexibility to change the code without worrying about breaking other potential users

Let me know what you think.

@mre I understand and agree with your recommendation - I am addressing this and, as well, the other review comments and republish for review - thanks for your patience!

mre · 2025-02-20T09:46:33Z

@thiru-appitap, I saw that you did some work. Can you close the resolved conversations already? It becomes a bit hard to keep track of the open TODOs. 😉
Also, did you use the "commit suggestion" feature from GitHub? For some of the changes, I made suggestions, which are easy to merge with a single click. This way, changes should be much easier to handle on your end. Of course, you have to git pull the changes locally to be up-to-date.

- moved (back) the textfrag as a module into the lychee-lib crate - added documents and ran doctests to verify its working - added a cli test to validate the text fragment functionality

thiru-appitap · 2025-02-21T19:47:06Z

@thiru-appitap, I saw that you did some work. Can you close the resolved conversations already? It becomes a bit hard to keep track of the open TODOs. 😉 Also, did you use the "commit suggestion" feature from GitHub? For some of the changes, I made suggestions, which are easy to merge with a single click. This way, changes should be much easier to handle on your end. Of course, you have to git pull the changes locally to be up-to-date.

@mre was juggling between couple of priorities, along with local travels and so couldn't resolve & commit the changes earlier itself - now on I should be able to get back with much faster turnaround on the feedback
now, the changes are all done (fingerscrossed) based on the feedback; along with, I have tried to adopt the idiomatic way as much as I could - willing to learn more and please keep helping me with more feedback!

almereyda · 2025-04-08T12:34:41Z

This branch kindly asks for a rebase.

Running cargo install --branch text-fragment --git https://github.com/thiru-appitap/lychee.git and then using lychee --include-text-fragments shows that this works in principle.

Would be nice to see this arrive.

thiru-appitap · 2025-04-10T14:48:23Z

This branch kindly asks for a rebase.

Running cargo install --branch text-fragment --git https://github.com/thiru-appitap/lychee.git and then using lychee --include-text-fragments shows that this works in principle.

Would be nice to see this arrive.

I have rebased the branch to the latest but am facing lint failures - working on to fix it and recommit by this weekend.

mre · 2025-05-09T16:09:39Z

I guess you can just do another rebase. We fixed the lint errors in master now.

mre · 2025-09-23T14:11:35Z

@thiru-appitap, would you like to continue working on this? Alternatively, we can close the PR. I still believe that it would be great to have this feature, but I'm not sure if anyone has the bandwidth to look into it at the moment.

Marzal · 2026-01-28T12:16:46Z

Thanks for working on this feature, It would be a great addition to Lychee

mre · 2026-01-29T10:03:01Z

Thanks for working on this feature, It would be a great addition to Lychee

The truth is that no one is working on this right now. 😞 We are looking for someone to pick up the work and fix the remaining issues mentioned in the comments of this PR.

Marzal · 2026-01-29T12:19:52Z

Well, I'm sorry to hear that and that I'm not a developer able to help here. But thanks anyway for the people who started the work, and for the future person* with enough free time and interest who get the functionality to the finish line.

I have faith on the FLOSS community.

PD: And of course to everyone involved on this project.

mre · 2026-01-29T13:47:39Z

Out of curiosity, what's your use-case for that feature?

Marzal · 2026-01-29T19:18:29Z

Out of curiosity, what's your use-case for that feature?

Hi, We have started using it on this GH Action [1] and this .lycheeignore [2] to check all the links of this web [3] and mainly this page [4].

Each feature should have a link to an explanation. And we had lots of errors and redirects before implementing Lychee 🫶 [5] The idea it's to point to the more accurate part of each page to make it easy to understand the tag/feature, given that it's a bit difficult for non tech people.

Example errors on [6]

[1] https://github.com/Podcastindex-org/web-ui/blob/master/.github/workflows/links.yml
[2] https://github.com/Podcastindex-org/web-ui/blob/master/.lycheeignore
[3] https://podcastindex.org/
[4] https://podcastindex.org/apps
[5] https://github.com/Marzal/web-ui/actions/workflows/links.yml
[6] https://github.com/Marzal/web-ui/actions/runs/21436605833#:~:text=Errors%20in%20server%2Fdata%2Fapps%2Ejson

thomas-zahner · 2026-01-29T20:36:48Z

@Marzal Thank you for letting us know the details. This really helps to understand the use-case and this way we already have test cases to cover.

In summary (for people working on this PR, or my future self) with --include-fragments we have a few links that are flagged as broken (Cannot find fragment) even though they work exactly as intended.

The workaround is the following .lycheeignore content:

# lychee does not understand search fragments
.*:~:text=.*

Affected links

https://beamly.com/exploring-the-new-standard-for-podcast-rss-feeds/#podcastpage-rss:~:text=added%20support%20to%20the%20following%20Podcast%202%2E0

https://blubrry.com/support/media-hosting-documentation/blubrry-dashboard-podcasting-2-0-features/#:~:text=Content%20Link

https://blubrry.com/support/powerpress-documentation/powerpress-podcasting-2-0-features/#content-link:~:text=Content%20Link

https://help.captivate.fm/en/article/captivate-feature-releases-changelog-vq1h56/#:~:text=OP3

I might actually find the time in the next few months to try and push this over the finish line, but no guarantees.

Marzal · 2026-01-29T20:54:43Z

Happy to help in any way I can like testing.

thiru-appitap and others added 3 commits December 25, 2024 01:56

Fragment Directive feature commit

7e1e2e1

Merge branch 'lycheeverse:master' into text-fragment

e3e09d6

verbose message clean-up

1085f7c

HU90m mentioned this pull request Dec 25, 2024

feature request: check text fragments #1545

Open

thiru-appitap added 2 commits December 25, 2024 03:28

cargo fmt fixes commit

584f460

clippy warnings fixed for test modules

b6d5b5a

mre reviewed Jan 10, 2025

View reviewed changes

mre requested changes Jan 10, 2025

View reviewed changes

Merge branch 'lycheeverse:master' into text-fragment

4ebb039

Merge branch 'lycheeverse:master' into text-fragment

c040e3a

Moved the text fragment feature into its own crate

6d99f78

lib's website checker continues to have the logic to validate text fragments clean-up of the tests were done review feedback incorporated - addressed structural, logic, tests and document comments

mre reviewed Feb 14, 2025

View reviewed changes

thiru-appitap and others added 3 commits February 21, 2025 12:55

Merge branch 'lycheeverse:master' into text-fragment

aaf9796

- refactored the text fragment code per review feedback

68bcd58

- moved (back) the textfrag as a module into the lychee-lib crate - added documents and ran doctests to verify its working - added a cli test to validate the text fragment functionality

lint (fmt) compliane failure fixes commit

e63bd50

Merge branch 'master' into text-fragment

61bbb58

mre assigned thomas-zahner and unassigned thomas-zahner Oct 9, 2025

thomas-zahner force-pushed the master branch 2 times, most recently from fcdf77c to e0912ab Compare October 21, 2025 12:53

Merge branch 'master' into text-fragment

38ddd3b

thomas-zahner mentioned this pull request Apr 13, 2026

Check text fragments #2138

Open


		use crate::types::TextDirective;

		const BLOCK_ELEMENTS: &[&str] = &[

	/// we will use the extension trait pattern to extend the Url to support Text Fragment feature
	/// We will use the extension trait pattern to extend [`url::Url`] to support the text fragment feature

	/// Checks if the url has a fragment and if the fragment is has the fragment directive delimiter embedded
	/// Checks if the url has a fragment and if the fragment has the fragment directive delimiter embedded

	/// Returns whether the URL has fragment directive or not
	/// Checks whether the URL has fragment directive or not

		@@ -0,0 +1,78 @@
		/// Defines the status of the Text Fragment search and extraction/search operation status

	/// Defines the status of the Text Fragment search and extraction/search operation status
	//! Defines the status of the Text Fragment search and extraction/search operation status


		use crate::types::{FragmentDirective, FRAGMENT_DIRECTIVE_DELIMITER};

		/// Fragment Directive feature trait

	/// Fragment Directive feature trait
	/// Fragment Directive extension trait


		use crate::types::{TextDirective, TextDirectiveKind, TextDirectiveStatus};

		const BLOCK_ELEMENTS: &[&str] = &[

Uh oh!

Conversation

thiru-appitap commented Dec 25, 2024 • edited by mre Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thiru-appitap commented Dec 25, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mre left a comment

Choose a reason for hiding this comment

Uh oh!

thiru-appitap commented Jan 12, 2025

Uh oh!

mre commented Feb 5, 2025

Uh oh!

thiru-appitap commented Feb 5, 2025

Uh oh!

mre commented Feb 6, 2025

Uh oh!

thiru-appitap commented Feb 12, 2025

Uh oh!

thiru-appitap commented Feb 14, 2025

Uh oh!

thiru-appitap commented Feb 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thiru-appitap commented Dec 25, 2024 •

edited by mre

Loading