Support multi-line annotations in task edit without JSON encoding

[jspricke]

To report a bug...

Since e4b9c1f annotations are JSON encoded in the editor making them hard to parse and edit. According to the ChangeLog this is only to escape newlines. I would propose replace newlines by \n (or some other char) and undo it after the edit.
I'm happy to implement this if you can confirm that the JSON encoding is only for the newline and that \n would be acceptable.

• What command(s) did you run?

task add foo
task 1 annotate https://taskwarrior.org/
task 1 edit

• What did you expect to happen?

see https://taskwarrior.org/ in the editor window

• What actually happened?

Annotation:        XXX -- https:\/\/www.taskwarrior.org\/

(JSON encoded URL)

• Paste the output of the task diag command.

> task diag

task 2.5.1
   Platform: Linux

Compiler
    Version: 9.2.1 20200224
       Caps: +stdc +stdc_hosted +c8 +i32 +l32 +vp32 +time_t32
 Compliance: C++11

Build Features
      CMake: 3.16.3
    libuuid: libuuid + uuid_unparse_lower
  libgnutls: 3.6.12
 Build type: None

Configuration
       File: /home/jspricke/.taskrc (found), 859 bytes, mode 100600
       Data: /home/jspricke/.task (found), dir, mode 40700
    Locking: Enabled
         GC: Enabled
    $EDITOR: nvim
     Server:
      Trust: strict
Certificate: , not readable, 0 bytes
        Key: , not readable, 0 bytes
    Ciphers: NORMAL
      Creds:

Hooks
     System: Enabled
   Location: /home/jspricke/.task/hooks
     Active: on-add    (executable)
             on-modify (executable) (symlink)
   Inactive:

Tests
      $TERM: tmux-256color (357x112)
       Dups: Scanned 415 tasks for duplicate UUIDs:
             No duplicates found
 Broken ref: Scanned 415 tasks for broken references:
             No broken references found

[tbabej]

@jspricke Confirming that this indeed seems to be the case. However, I'm not sure using an escape character is the way to go. What if the annotation itself already contains (escaped) \n character? Now both escaped and unescaped newlines would be represented by the same character.

Maybe the right way forward would be to support multi-line annotations in the task edit directly. A little bit more difficult to parse, but much more convenient to work with from the user end.

[jspricke]

With multi-lines annotations you would need to define when a multi-line annotation ends and you could have lines like annotations in annotations...

I would add on backslash to every \n and reverse it afterwards, so an (escaped) \\n would be shown as \\\n.

[tbabej]

@jspricke I'm thinking syntax like this, which should be unambiguous:

  Annotation:        2021-01-04 19:01:20 -- First annotatation
                     and here it continues
                     possibly over multiple lines
                     there could be even a timestamp
                     2021-01-04 19:01:20 -- and it would not matter unless the line starts with Annotation:
                     so still part of the first annotation
  Annotation:        2021-01-04 19:01:41 -- Second annotatation
  Annotation:        2021-01-04 19:01:47 -- 

What you're proposing should also work though, might be a good temporary fix before we implement multi-line annotation support.