Large rework of how virtual text properties are stored, plus multiple other property bug fixes. by paul-ollis · Pull Request #19685 · vim/vim

paul-ollis · 2026-03-14T15:48:05Z

My apologies for the size of this PR, but the fix for #19680 and #19681
required some major redesign/rework. During the course of those changes other
issues became apparent, which I felt could not be disentangled into separate
PRs.

The issues that this PR addresses are: #12568, #19256, #12677, #12678, #12679,
#12680, #12681, #12682, #12683 and #12684.

The major change is to store the text for virtual text properties within the
memline instead of a special table attached to the buffer. This change:

Makes undo/redo robust when virtual text properties are used (Undo/redo can fail for virtual text properties. #19680).
Stops ever increasing memory usage by the table mentioned above (Virtual text properties consume ever increasing memory as they are added/deleted. #19681).
Removes the restriction about using negative property IDs.

The changes to the property help file reflects the removal of the above
restriction and also include some corrections/clarifications.

I created quite a few additional tests in test_textprop2.vim, which uses
textprop_support.vim and textprop.py to "model" properties. The
textprop_support.vim provides a "facade" class that delegates to a class in
textprop.py.

The reason for this structure and the use of Python is quite simply that I found
writing the "model" using VimScript too difficult. Perhaps another person might
be able turn the "facade" in textprop_support.vim into a pure VimScript
implementation. But, sorry, it will not be me.

There are also a number of small changes to test scripts, which allowed me to
run the tests reliably on my local PC.

64-bitman · 2026-03-14T18:23:17Z

I wonder if this conflicts with #19661, that PR only modifies the drawing code.

paul-ollis · 2026-03-14T18:43:41Z

@64-bitman. Yes #19661 does conflict.

I am clearly some way off getting a stable CI run, but assuming both PRs are accepted then I think there will be a tricky re-base regardless of which PR get merged first.

h-east

About the document.

Write according to the rules.

:h help-writing
/^STYLE

The following two points are particularly important:

Vim help files generally use 2 spaces after a sentence (since they are written
using a fixed-width font and that was the preferred style in the 70s/80s),
like what is described here: https://english.stackexchange.com/a/2602

(snip...)

Use two spaces between the final dot of a sentence of the first letter of the
next sentence.

h-east · 2026-03-15T10:38:25Z

src/testdir/test_textprop.vim

      edit foobar
      set nowrap
-      set showbreak=+++\ 
+      set showbreak=+++\


This doesn't seem to be the intended fix.

My vim configuration automatically removes trailing white space "noise" because, well it is "noise" and can only confuse.

I did notice the change had crept in but (a) the test still passes and (b) there is nothing to indicate that anyone thought the space to be important.

I see no good deliberately add the space back in.

That's a bit of a stretch.
In Markdown files, removing trailing whitespace changes the layout.
Similarly, removing trailing whitespace in Vim scripts can cause unintended behavior or test failures.
Could you please revert it?

Below is a list (grep result) of lines that require trailing whitespace as intended for the test.

test_conceal.vim|151 col 24-26| set showbreak=\ >>>\ test_display.vim|345 col 21-23| set fillchars=eob:\ test_display.vim|416 col 28-30| set fillchars+=foldinner:\ test_listchars.vim|414 col 34-36| set listchars=tab:>-,leadtab:\|\ test_listchars.vim|422 col 35-37| set listchars=tab:>-,leadtab:│\ test_popupwin.vim|1168 col 19-21| set showbreak=>>\ test_scroll_opt.vim|520 col 49-51| set smoothscroll scrolloff=0 showbreak=+++\ test_signs.vim|168 col 42-44| sign define Sign5 linehl=Comment text=X\ test_textprop.vim|3609 col 24-26| set showbreak=+++\ test_textprop.vim|4276 col 20-22| set showbreak=>\

The backslash in that value is only present to escape the trailing space character and include it in the value. The trailing backspace now makes no sense. Set it with :let if you like but the change is, I assume, irrelevant to the PR anyway.

It looks like the test passes because the wrapped line is now overwritten by the virtual text.

@h-east and @dkearns. Thanks for your comments.

I have had a closer look at the test in question and the showbreak setting
appears to serve no purpose, except possibly to prove that showbreak has no
effect in the test's setup.

So, I have removed the "" character as well, which at prevents the test
remaining such a puzzle.

If anyone knows (or suspects) that the test is broken and should be investigated
further then please raise an issue.

From 48ca24d it would appear it's included just to confirm that it's not drawn.

You're probably now aware but +++ is a pseudo default value as it's a prominent example at :help showbreak.

However, it's inconsistently used even in this test file and there are also some other examples of trailing single backslashes, which I've always considered a rather ugly exception to the \\ literal backslash rule.

:g/showbreak= setlocal number showbreak=+ breakindent breakindentopt=shift:2 setlocal linebreak showbreak=+ breakindent breakindentopt=shift:2 call term_sendkeys(buf, ":set showbreak=+++\<CR>") set showbreak=+++ set showbreak=+++ set showbreak=+++ set showbreak=+++\ call term_sendkeys(buf, ":set showbreak=>>\<CR>") call term_sendkeys(buf, ":set showbreak=\<CR>") set showbreak=>\ set cursorline scrolloff=0 showbreak=>\ smoothscroll

But let's not derail this commentary any further...

h-east · 2026-03-15T11:15:36Z

src/structs.h

+    buf_T      *buf;	      // [R]  The line's buffer.
+    linenr_T   lnum;	      // [R]  The number of the line. May be zero to
+			      //      indicate that no line is loaded.
+    bool       detached;      // [R]  When set, "text" and property virtual text
+			      //      is allocated.
+    colnr_T    text_size;     // [R]  Size of text including NUL.
+    char_u     *text;	      // [R]  Just the NUL terminated text.
+    uint16_t   prop_size;     // [P]  The number of allocated "props".
+    uint16_t   prop_count;    // [R]  The number of properties.
+    textprop_T *props;	      // [R]  Variable length vector of properties. Treat
+			      //      as read-only unless detached is true.
+    bool       text_changed;  // [P]  The text has been changed. Note "detached"
+			      //      must also be set.
+    int        adjust_flags;  //      Flags controlling "prev" and "next"
+			      //      adjustments.
+
+    // Next and previous lines, used to adjust neighbouring properties.


Generally, single-sentence code comments do not contain periods. While there are no specific rules regarding this, I believe it's the same in Viim.

The same applies to code comments outside of this section.

I try to respect the existing style of a code base but properly punctuated, single sentence comments appear
elsewhere within the code. I chose to follow that style because it fits with philosophy.

I much prefer properly punctuated comments, not least because it is respectful of the reader.

This simplifies the code in many ways as well as fixing a number of bugs and effective deliberate memory "leaking" required to make undo (mostly) work with properties. Signed-off-by: Paul Ollis <paul@cleversheep.org>

Moved text property testing support files to testdir/util.

- Moved text property testing support files to testdir/util. - Get memline more often in indent.c. May fix random lispindent failures. - Fix use of null pointer in textprop.c. - Added free for individual detached properties in charset.c. - Increased wait for a flaky screen dump test.

64-bitman · 2026-03-16T16:06:36Z

src/textprop.c

 }

 #endif // FEAT_PROP_POPUP
+


I think these notes should be at the top of the file

@64-bitman. An interesting comment. I actually did have the notes at the top then moved the bottom because there was a lot of comment to scroll through in order to get to the code. In my (disturbingly) long career I have encountered more people who, in such cases, prefer such details to be tucked away at the bottom of the file.

I do not have strong feelings either way (at least as far as this PR goes) and will happily follow consensus or an authoritative steer from the core team.

It seems we have a consensus of one, so I am moving the notes to the top of the file.

zeertzjq · 2026-03-17T07:45:34Z

src/testdir/test_ins_complete.vim

  " this was reading past the end of the line
  new
-  norm 8oý 
+  norm 8oý


This trailing space is inserted as buffer text. It should be kept.

Extremely well spotted. I would never known.

Changing to execute "normal 8oý " so that this is no longer so fragile.

@paul-ollis
Could you please revert the following settings?

My vim configuration automatically removes trailing white space "noise" because, well it is "noise" and can only confuse.

You are modifying parts that don't need to be changed, seemingly without realizing it. It's becoming counterproductive because you're trying to apply even more changes to address the unexpected side effects I've pointed out. These lines are there for a reason and are not "noise," so please leave them as they are.

ADD:
If changes are necessary, they should be made in a separate pull request, not this PR.
I would appreciate it if you would focus your efforts on the text property.

paul-ollis · 2026-03-17T15:23:46Z

UPDATE:
I figured out my dumb mistake. Problem solved. Thanks for those who made suggestions.

So, the CI build is stubbornly refusing to run clean because this error on "huge" builds.

Failures:
	From test_textprop2.vim:
	Caught exception: Vim(import):E1053: Could not import "./util/textprop_support.vim"
        @ command line
            script /home/runner/work/vim/vim/src/testdir/runtest.vim[567]
            /home/runner/work/vim/vim/src/testdir/test_textprop2.vim, line 9

And I am frankly currently baffled. The problem does not occur for the "normal" build (the test script runs and passes fine). There should be no reason for the "huge" build to work as well. At the point of the failure, Vim is just sourcing some code and, as part of that, loading some Python 3 code. Python 3 is enabled and the Python 3 tests are running and passing.

Any ideas, suggestions or help about how to figure out the problem would be very gratefully received. I have tried to replicate the "huge" build on my local PC and am pretty sure I have succeeded with something that is very close. For me the tests run fine.

I am about to try some experimenting which will, temporarily, break other tests so I will make this PR draft for a while.

64-bitman · 2026-03-17T17:03:59Z

So, the CI build is stubbornly refusing to run clean because this error on "huge" builds.
Failures:

	From test_textprop2.vim:

	Caught exception: Vim(import):E1053: Could not import "./util/textprop_support.vim"

        @ command line

            script /home/runner/work/vim/vim/src/testdir/runtest.vim[567]

            /home/runner/work/vim/vim/src/testdir/test_textprop2.vim, line 9
And I am frankly currently baffled. The problem does not occur for the "normal" build (the test script runs and passes fine). There should be no reason for the "huge" build to work as well. At the point of the failure, Vim is just sourcing some code and, as part of that, loading some Python 3 code. Python 3 is enabled and the Python 3 tests are running and passing.

Any ideas, suggestions or help about how to figure out the problem would be very gratefully received. I have tried to replicate the "huge" build on my local PC and am pretty sure I have succeeded with something that is very close. For me the tests run fine.

I am about to try some experimenting which will, temporarily, break other tests so I will make this PR draft for a while.

In test_textprop2, i don't think you can use the import command in legacy vim script

paul-ollis · 2026-03-17T17:25:13Z

In test_textprop2, i don't think you can use the import command in legacy vim script.

Thank for the suggestion, but - no it works. The test_textprop2.vim script works absolutely fine for the "normal" build.
In fact, a bunch of (legacy vim) test scripts do "import './util/vim9.vim' as v9"

Once again thanks.

... which I dumbly lost during a file move and branch cleanup.

chrisbra

I found a few issues. Some are style (like braces for single statements, using the FASE/TRUE macros for booleans, using free() instead of vim_free(). Then there is at least a potential double free in prop_add_one() and the error case in perform_properties_adjustment() on um_detach() failure looks a bit suspicious.

chrisbra · 2026-03-22T17:39:40Z

src/change.c

 */
    void
-del_lines(long nlines,	int undo)
+del_lines(long nlines,int undo, int flags)


please keep the space after nlines

Fixed for next push.

chrisbra · 2026-03-22T17:40:51Z

src/testdir/test_textprop.vim

  call StopVimInTerminal(buf)
 endfunc

-func Test_error_when_using_negative_id()


Why is this deleted? This test and the next one should be kept, no?

Hi Chris, thanks for finding the time to review this.

Perhaps this is comment and the need to rebase the PR in light of #19741, is a
good trigger to discuss just totally simplifying positive and negative IDs.

[Please be aware that I was pretty exhausted by the time I submitted this PR.
What I expected to be a small fix turned into fixing non-trivial design flaws,
wading through technical debt and, frankly, some code that long ago became way
too hard to maintain.

By the end, the desire to keep the PR well focused conflicted with a desire to
simply get the PR submitted. I am painfully aware that I may have failed to
acheive the correct balance - for which I apologise. With that in mind...]

As I understand it, the restrictions on when negative IDs could be used were
only ever required because of the way that the text for virtual text properties
was separately stored; using negative IDs as an index. In other words, the
introduction of virtual text properties allowed implementation details to
leak into and complicate the text property API.

As a result of this PR the need for the restrictions disappeared and the
associated code covered by these tests "disolved", as I recall. The code for
using negative IDs for virtual text properties did "survive" albeit in
simplified form.

Thinking about this again, I cannot see any technical reason to place any
restrictions on IDs. That is, if the user supplies a value for the ID then
there is no technical reason that the provided ID should not be used.

The current (master) API rules feel like a bit of a mess to me. It would be
good to make them at least well defined before I rebase.

chrisbra · 2026-03-22T17:45:22Z

src/drawline.c

+			textprop_T *tp = &text_props[used_tpi];
+			char_u	   *p = tp->tp_id != -MAXCOL ? tp->tp_text : NULL;
+			int	   above = PROP_IS_ABOVE(tp);
+			int	   bail_out = FALSE;


I agree, but it is existing code. Is changing the types for "bail_out" and "above" acceptable code churn?

chrisbra · 2026-03-22T17:46:03Z

src/errors.h

-#ifdef FEAT_PROP_POPUP
-EXTERN char e_cannot_add_textprop_with_text_after_using_textprop_with_negative_id[]
-	INIT(= N_("E1339: Cannot add a textprop with text after using a textprop with a negative id"));
-#endif


can you update the comment above?

src/ex_cmds.c

chrisbra · 2026-03-22T19:46:36Z

src/textprop.c

+    if (umemline->text != NULL)
+    {
+	umemline->text = vim_strsave(umemline->text);
+    }


can drop the braces again

chrisbra · 2026-03-22T19:49:46Z

src/textprop.c

+    return TRUE;
+
+fail:
+    free(umemline->text);


umemline->text = NULL;

chrisbra · 2026-03-22T19:50:34Z

src/textprop.c

+    for (int j = 0; j < i; j++)
+    {
+	free(umemline->props[j].tp_text);
+    }


I am wondering, if we should do um_abort() here?

chrisbra · 2026-03-22T19:58:29Z

src/textprop.c

+	int is_vtext = PROP_IS_VTEXT(prop);
+	prop_mod_T result = adjust(prop, col, count);
+	if (result != PC_UNMODIFIED && !um_detach(&umemline))
+	    break;


if um_detach() fails midway in this loop, we break out and then close the inconsistent umemline.

chrisbra · 2026-03-22T20:03:02Z

src/textprop.c

-	buf->b_ml.ml_line_ptr = newtext;
-	buf->b_ml.ml_line_len += sizeof(textprop_T);
-	buf->b_ml.ml_flags |= ML_LINE_DIRTY;
+	tmp_prop.tp_text = virt_text;


this causes a double free in case of an error.

Co-authored-by: Christian Brabandt <cb@256bit.org>

h-east

I have strong reservations about addressing multiple distinct issues/improvements within a single PR. Whether such a major logic change is truly necessary remains a matter of debate. First and foremost, each issue should be handled individually.

Furthermore, I fail to understand the refusal to comply with requests from Vim members regarding non-essential parts of the PR.
#19685 (comment)
#19685 (comment)

h-east · 2026-03-26T01:40:46Z

Review result

Bugs

Memory leak in perform_properties_adjustment
When u_save() fails, the function returns without calling um_abort(&umemline),
leaking the detached umemline.
Dead code in remove_bytes_1
In the virtual text branch, after last_deleted_byte >= prop->tp_col already
returns PC_RQ_DELETE, the subsequent prop->tp_col <= last_deleted_byte check
is unreachable. The prop->tp_col = col assignment never executes.
vt_id_counter overflow
The global counter decrements monotonically with no wraparound guard. It will
hit INT_MIN and cause undefined behavior in very long-running sessions.
Test_subst_adjusts_marks early return
There is a bare return after the first LoadEditAndCheck call, causing the
remaining 7 test cases to be silently skipped. Likely a debug leftover.
Double free (noted by @chrisbra at line ~1318)
The error path can trigger a double free. This was flagged in the code review
but it's unclear whether it has been fully resolved.

Unused code

The vtext_T struct (with ref_count) is defined in structs.h but never
referenced anywhere in the codebase. Should be removed or deferred to when
it's actually needed.

Code style

Numerous typos in comments: "typs", "propery", "memorry", "hae", "nolonger",
"writaing", "propbably", "responsibilty", "reomving"
Mixed bool/true/false and int/TRUE/FALSE — Vim traditionally uses the
latter. @chrisbra's review also touched on this but the direction seems
inconsistent across the PR.
ERR_FAIL/ERR_RET macros using comma operators are hard to read.
#define COPY_PROPS true style is unusual for the Vim codebase.

Tests

Python test model (textprop.py, 1017 lines):

Requires CheckFeature python3, so all new tests in test_textprop2.vim are
silently skipped on builds without Python3.
This is a significant departure from Vim's self-contained testing
philosophy.
The Python code itself has bugs: dead code in test_delete (code after
return), a duplicate condition in insert_text, and incorrect type annotation
string (should be str).

Removed tests:

Test_removed_prop_with_text_cleans_up_array,
Test_error_when_using_negative_id, Test_error_after_using_negative_id are
deleted. The removals are consistent with the design change, but there should
be a replacement test verifying that negative IDs now work without error.

Documentation

Typo in textprop.txt: *before" should be before (missing closing
asterisk).
prop_list() sort description changed from "ordered by starting column and
priority" to "ordered by starting column" — is the removal of priority sorting
intentional?

Unrelated changes

The following are mixed into this PR but are unrelated to text property
rework. They make bisecting harder and should ideally be in a separate PR:

g:ignoreSwapExists additions (test_cmdmods.vim, test_codestyle.vim,
test_search.vim, test_window_cmd.vim)
--noplugin additions (test_crash.vim, test_gui.vim, test_options.vim,
test_startup.vim)
TermWait timeout change (test_messages.vim)
Trailing whitespace removal (test_ins_complete.vim)
Typo fix (test_substitute.vim)
Indent fix (socketserver.vim)

Summary

Memory leak and potential double free bugs
The early return in Test_subst_adjusts_marks skipping most test cases
Separation of unrelated changes
The Python test dependency question

h-east · 2026-03-27T16:58:23Z

I removed the Python dependency from test_textprop2.vim and made it a pure Vim script. (All 13 tests passed)
https://gist.github.com/h-east/29e80dec65f7ef14befa8007888e62c2
It can be replaced.

textprop.py and textprop_support.vim widthin testdir/util/ can be deleted.

paul-ollis · 2026-03-27T18:59:03Z

So I have been snatching odd, currently very precious, moments to try to keep
working on this PR. I have just found time to do a full scan to check the
status of the comments that I have not been able to fully address yet and find
the above.

This PR is big. It took up far more of my time than I expected, more than I
wanted to spend on it and, frankly, more than I could really afford.

It is quite likely that some major changes might be required for the PR, not
least of which might be that others might spot ways in which it might be broken
down into some smaller changes. The review process provides a mechanism to have
a conversation about such issues. A conversation!

But this is not a conversation and, as things stand, I am not willing to engage
with this PR any further.

My previous contributions have been pleasant experiences and, I hope, useful.
However, for the foreseeable future I will not be visiting the Vim issues or
PR lists.

I can be contacted directly via email.

h-east · 2026-03-27T20:21:39Z

@paul-ollis
My requests were made to ensure the sustainable maintenance of Vim as a team member. Regrettably, I've seen very little cooperation in response to them.

Participating in open source requires a degree of flexibility and a willingness to compromise.

yegappan · 2026-03-27T20:55:04Z

So I have been snatching odd, currently very precious, moments to try to keep working on this PR. I have just found time to do a full scan to check the status of the comments that I have not been able to fully address yet and find the above.

This PR is big. It took up far more of my time than I expected, more than I wanted to spend on it and, frankly, more than I could really afford.

It is quite likely that some major changes might be required for the PR, not least of which might be that others might spot ways in which it might be broken down into some smaller changes. The review process provides a mechanism to have a conversation about such issues. A conversation!

But this is not a conversation and, as things stand, I am not willing to engage with this PR any further.

My previous contributions have been pleasant experiences and, I hope, useful. However, for the foreseeable future I will not be visiting the Vim issues or PR lists.

I can be contacted directly via email.

@paul-ollis Thank you for the significant effort you've put into this. The listener functionality is important for the Language Server Protocol support, and your work on improving this is appreciated.
Regards,

chrisbra · 2026-03-28T09:52:10Z

@paul-ollis thanks for all the work you put into Vim and improve the listener and text-properties support. Hope to see you back eventually

paul-ollis force-pushed the issue_12568 branch from 1139dd5 to d947e58 Compare March 14, 2026 18:21

paul-ollis force-pushed the issue_12568 branch from d947e58 to 8406b9c Compare March 15, 2026 08:58

h-east reviewed Mar 15, 2026

View reviewed changes

paul-ollis force-pushed the issue_12568 branch from 8406b9c to f01d46c Compare March 15, 2026 13:14

paul-ollis added 2 commits March 15, 2026 15:45

Store virtual text in memline.

a7e2983

This simplifies the code in many ways as well as fixing a number of bugs and effective deliberate memory "leaking" required to make undo (mostly) work with properties. Signed-off-by: Paul Ollis <paul@cleversheep.org>

Get PR tests to run clean.

3a02f2b

Moved text property testing support files to testdir/util.

paul-ollis force-pushed the issue_12568 branch from f01d46c to 0a1a071 Compare March 15, 2026 15:45

paul-ollis force-pushed the issue_12568 branch from 0a1a071 to e70e002 Compare March 15, 2026 19:33

64-bitman mentioned this pull request Mar 16, 2026

Allow virtual text to overlay buffer text #19661

Open

paul-ollis mentioned this pull request Mar 16, 2026

The lispindent() function does not take inline virtual text properties into account. #19721

Open

64-bitman reviewed Mar 16, 2026

View reviewed changes

paul-ollis mentioned this pull request Mar 16, 2026

The prop_add() function allows text and id to be set. #19684

Open

Mainly fixing AddressSanitizer errors.

2dc0d60

zeertzjq reviewed Mar 17, 2026

View reviewed changes

paul-ollis marked this pull request as draft March 17, 2026 15:23

paul-ollis added 2 commits March 17, 2026 16:30

Fix for some dumb finger trouble.

cfa2021

Avoid use of trailing white space in test.

8eae756

Add missing files ...

6f51ba7

... which I dumbly lost during a file move and branch cleanup.

paul-ollis marked this pull request as ready for review March 19, 2026 08:51

chrisbra reviewed Mar 22, 2026

View reviewed changes

paul-ollis and others added 2 commits March 25, 2026 16:57

Apply suggestions from code review

535bac0

Co-authored-by: Christian Brabandt <cb@256bit.org>

Changes from code reviewing.

88bfea8

chrisbra mentioned this pull request Mar 25, 2026

virtual text property IDs are not recycled after deletion #19823

Closed

h-east requested changes Mar 26, 2026

View reviewed changes

h-east mentioned this pull request Mar 27, 2026

Change some tests to avoid trailing whitespace. #19838

Open

Uh oh!

Conversation

paul-ollis commented Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

64-bitman commented Mar 14, 2026

Uh oh!

paul-ollis commented Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

h-east left a comment

Choose a reason for hiding this comment

About the document.

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!

dkearns Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dkearns Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paul-ollis Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

h-east Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paul-ollis commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

64-bitman commented Mar 17, 2026

Uh oh!

paul-ollis commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chrisbra left a comment

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paul-ollis commented Mar 14, 2026 •

edited

Loading

paul-ollis commented Mar 14, 2026 •

edited

Loading

dkearns Mar 15, 2026 •

edited

Loading

dkearns Mar 17, 2026 •

edited

Loading

paul-ollis Mar 15, 2026 •

edited

Loading

h-east Mar 17, 2026 •

edited

Loading

paul-ollis commented Mar 17, 2026 •

edited

Loading

paul-ollis commented Mar 17, 2026 •

edited

Loading