Multi line text field support (needs testing)

[ransome1]

Hello everyone,

Despite its small appearance, this feature caused some challenges during implementation.

I could use some assistance here. Would you kindly download developer preview 17 and experiment with the multi-line text field?

The testing should concentrate on the following aspects:

• Switching between single and multi-line modes.
• Ensuring that line breaks are preserved when switching.
• Adding and editing dates, priorities, pomodoro intervals, contexts, and projects in both single and multi-line modes.
• Confirming that the single or multi-line text field persists when the app is closed and reopened.
• Visual issues.

[swantzter]

(splitting my notes into multiple comments to be able to have separate response threads)
It doesn't seem like any of the keyboard-only shortcuts I expect to enter multi-line mode works (Shift+Enter, Ctrl+Enter - with a preference for the former) making this feature seem to require mouse input.

[swantzter]

Line breaks are preserved for me when switching, but it'd be nice if the font could render a symbol instead of a white square (□), maybe the glyph used for U+23CE (return symbol, ⏎) could be used (while still using U+0010 in the text field)

[swantzter]

Editing due dates doesn't work for me if the due date is at the start of a new line (it adds an additional due date instead) ([dle]due:2023-10-25), it works if I begin the line with a space, so perhaps the line break symbol isn't considered as whitespace.

[swantzter]

I'd like to make some suggestions for how multiline TODO's are displayed in the text view.
I think it'd be nice if the first row had a normal font size, (if that "line" spans multiple rows when rendered I think it should keep that size) but additional rows should be a smaller font size, and maybe even a slightly more dim color.

It would also be nice (maybe as a setting) to only show idk one/two rendered lines in that small size, and have an ellipsis - and then perhaps a caret (basically a <details/>) on the far right side allowing you to expand it to view the full TODO.

crude text example:

◯ THIS IS THE FIRST LINE IN LARGE FONT SIZE (ILLUSTRATED BY HERE ALL-CAPS)    ▼
   Here are line two for +project @context for the todo in smaller font...

and expanded

◯ THIS IS THE FIRST LINE IN LARGE FONT SIZE (ILLUSTRATED HERE BY ALL-CAPS)    ▲
   Here are line two for +project @context for the todo in smaller font
   illustrated by normal capitalisation. As it got longer it wasn't
   allowed to overflow the container and was thus cut off with an
   ellipsis. But by clicking the expand (▼) icon the full TODO with
   all of it's line breaks where expanded for viewing.
   
   due:2023-10-27

[swantzter]

Iterating on this from reading #620 and #622.
I'm torn on modifying the order of task elements like that, on one hand it could be useful in a lot of circumstances and could be rendered pretty nice - but on the other hand in some instances the placement of a +project, @context, or due:/t:/rec: in the task's text is very deliberate.

Thus I'm thinking projects, contexts and tags specified first or last (with no "normal text" before (except creation date and prio) or after) in the task would get hidden from the main part and rendered separately, but these elements in the middle of the task body would stay in and be duplicated in a separate summary UI.

◯ THIS IS THE FIRST LINE IN LARGE FONT SIZE (ILLUSTRATED BY HERE ALL-CAPS)    ▼
   Here are line two for +project @context for the todo in smaller font...
   📅 Tomorrow 🔁 every 2 business days +a-project +b-project @context

and expanded

◯ THIS IS THE FIRST LINE IN LARGE FONT SIZE (ILLUSTRATED HERE BY ALL-CAPS)    ▲
   Here are line two for +project @context for the todo in smaller font
   illustrated by normal capitalisation. As it got longer it wasn't
   allowed to overflow the container and was thus cut off with an
   ellipsis. +b-project But by clicking the expand (▼) icon the full
   TODO with all of it's line breaks where expanded for viewing.

   // this isn't rendered: due:2023-10-27 @context +a-project rec:2b

   📅 Tomorrow 🔁 every 2 business days +a-project +b-project @context

I'm imagining the following styling:

• 1st: row "normal" font colour 1rem font size
• details: "dim" font colour, smaller font size. When task is expanded add a bit of margin at the bottom to distance it a little (not a full line) from the last summary row
• last row: same font size as the details. Use the already existing elements for tags, projects and context visualisation, kinda:
  • for due date maybe use a calendar/clock icon (or use due: in the left part of the tag "pill") and a relative date (for today, tomorrow, yesterday) or human formatted date ("15 jan" - hide year for same year, "15 jan 2025" - show date for next/prev year). (from Add options to show dates (esp. Due Date) as relative ("Today"/"2 days from now"/"2 weeks from now") on each item #609) You could also play around with colour of one of the halves of the pill, default colour when far our, one colour when it's within a week from now, one colour for tomorrow, one colour for today, and one for past due)
  • for recurrence use a recurring icon (or use rec:) and a human readable rendition (like "every 2 business days" instead of 2b"
  • projects and contexts are displayed as today, but they're sorted alphabetically and showing uniques, projects are displayed first then contexts.

[dlaidig]

// this isn't rendered: due:2023-10-27 @context +a-project rec:2b

Just to clarify: Why is this line not rendered? Is it because your proposal includes a comment syntax with //? It it because it is separated by an empty line? Is it because the content is just too long?

[swantzter]

@dlaidig because they end the task with no "normal text" after. Similar to how I'd move if it started the task with no normal text before. That's what I mean by this section before the code block

Thus I'm thinking projects, contexts and tags specified first or last (with no "normal text" before (except creation date and prio) or after) in the task would get hidden from the main part and rendered separately, but these elements in the middle of the task body would stay in and be duplicated in a separate summary UI.

[dlaidig]

Ah, this wasn't clear to me. I thought the whole line, including // this isn't rendered:, would not get rendered. Thanks!

Unrelated side note: Not sure what I think about this part of the proposal. One thought, however, is that for the example given in the todo.txt specification (https://github.com/todotxt/todo.txt), the item measure space for +chapelShelving @chapel due:2016-05-30 would turn into measure space for. In generally, I would personally like to keep the current simple one-line view with the option to expand further details.

[swantzter]

Yeah, I don't think that example should be altered. I guess I should clarify to "beginning of first line" and "ending of Last line - if more than one line"