Marked notes

[cmjmmrp-byte]

Hi, is it possible to check the box without having to write in Markdown? Thanks

[ulsklyc]

Yes and no, and the no is the interesting half.

You never have to write Markdown by hand. The note editor has a toolbar, and one of its buttons inserts a checkbox item (- [ ]) for you, the same way the bold and list buttons work. So creating a checklist needs no syntax knowledge at all. If that button was not findable, that is useful feedback in itself.

What you cannot do is tick the box by tapping it, and I suspect that is what you were actually asking. The rendered checkbox is a <span aria-hidden="true">, which is to say decoration, not a control. To check an item today you open the note, change [ ] to [x] in the text, and save. For a shopping or packing list on the wall tablet that is three steps too many, and it makes the feature look broken even though it renders correctly.

So: half of your question has a good answer, and the half you ran into is a real gap. Making rendered checkboxes tappable is accepted. Two things it has to get right, which is why it is not quite a one-liner:

• ticking a box rewrites the note body, so it has to touch only the one item and leave the rest of the text byte for byte alone
• notes are shared, so two people ticking different items at the same time must not have one overwrite the other's line

Thanks for asking. This one had been sitting in plain sight.

[ulsklyc]

Short answer: no, not today, and both halves of your question are fair.

What you are seeing in the screenshots is the rendered view. renderMarkdownLight() draws a checklist item as a styled box that is deliberately inert (aria-hidden), so it looks like a checkbox but is not one. To tick something off you have to open the editor and change - [ ] into - [x] by hand, which is exactly the detour you are describing.

Two separate things are missing, and I want to name them apart because they are not the same amount of work:

1. Tapping the rendered box. The obstacle is not the click handler, it is the write-back: the tap has to find which - [ ] line in the source text the third box in the output belongs to, and put an x in that one and no other. The same renderer is used by Notes, Tasks and the dashboard, so that mapping has to be built once and correctly rather than three times. Accepted, and it is the more useful half.

2. Inserting a checkbox without typing the brackets. The Notes editor has a formatting toolbar; a checklist button belongs in it. @thesoundhead asked for the same thing for task notes in #731, on a phone, for the same reason. Same job, two places.

No date from me. Thanks for the screenshots, they made it obvious that the box looks interactive, which is its own problem regardless of when this gets built.

[Imanity-jhn]

I fully support the original request. Being able to check or uncheck checklist items directly by clicking the checkbox would fit perfectly into a quality-of-life update. As it stands, checklist items in the Notes module are particularly cumbersome to use, since users have to edit the note and manually add or remove an “x” each time. Making the rendered checkboxes interactive would provide a much smoother and more intuitive experience.

[Imanity-jhn]

I’m bringing this up again because it’s really annoying when you use the feature regularly.

[ulsklyc]

You are right to push, and the honest answer is that my last reply overstated the obstacle.

I said the blocker was the write-back: that a tap has to work out which - [ ] line in the source text the third box in the output belongs to. Going back to the renderer, that mapping is not something that needs building. renderMarkdownLight() already walks the note line by line, so at the moment it emits a checklist item it knows exactly which source line produced it. Carrying that index onto the element is an attribute, not an algorithm. Ticking then rewrites one line by its number, which is also what makes it safe: no text matching, so two items reading "Milk" are not a problem.

That changes my assessment of the work rather than the priority, and I would rather say so than leave a wrong reason standing for a third time.

What is genuinely left, and it is the smaller half:

• The renderer is shared. Notes, Tasks and the dashboard all draw through it. So the renderer marks the line and each caller decides whether its boxes are live. On the dashboard they must not be: notes are shown there as a truncated excerpt, and an excerpt has no reliable line numbers.
• Two people, one note. Saving currently writes the whole body. Two members ticking different items in the same minute would have the last save win and silently drop the other tick. Rewriting a single line by index is what makes a narrower save possible, so this is a thing to get right rather than a reason not to start.

So: accepted for the third time, but with a route instead of a caveat. The checklist button for the editor toolbar goes in with it, since @thesoundhead asked for the same thing on the task side in #731 and it is the same job in two places.

No date from me, and I am not going to invent one to end a thread. But it is now sized as an evening rather than a project, and it moves accordingly.

[ulsklyc]

This shipped in v2.42.0.

@Imanity-jhn you pushed twice, and the second time you were right to: the last thing I said was that it had been resized "as an evening rather than a project", and then it sat there anyway. Tapping a rendered checkbox now ticks it, on the note card and in the reader.

Two things about how it works, because they decide where it does not work.

A tick rewrites one line, not the note. Notes are shared. If ticking had gone through the ordinary save, two people crossing off different items in the same minute would have had the later save quietly drop the earlier tick - and nobody would have seen it happen, because both taps looked like they worked. It goes through a route of its own that changes exactly the one line and leaves the rest of the text byte for byte alone.

Which line is meant comes from the line number, never from the text. A shopping list with "Milk" on it twice is the normal case, not an edge case. The renderer marks each box with the line it came from, and the client sends back the line it saw; if somebody edited the note in between, the tick is refused rather than landing in the wrong row. You would see a message and the note reloading - rare, but that is what it means.

Where boxes stay decorative, and why. On the overview, because the note is shown there as a truncated excerpt and an excerpt's line numbers are not the note's. In task notes, which have no line-accurate way back to the text yet. And in the reader while the editor holds unsaved changes, because those lines are not the lines the server has. In all three the box looks the same as before and simply does not respond - I would rather it do nothing than tick the wrong thing.

The checklist button in the editor toolbar was already there, so you never had to type the brackets by hand either; if it was not findable, that is worth its own thread.

Thanks for not letting this go.