Manual 'double up' arrow doesn't change task priority if followed by Variant Selector

[JasonBates]

Please check that this issue hasn't been reported before.

• [X] I searched previous Bug Reports didn't find any similar reports.

Expected Behavior

Appending a double up arrow to the end of a task should give that task a high priority

Current behaviour

Appending a double up arrow to a task does not change the task priority.

This is an anomoly as:

• appending a single up arrow to a task changes the priority of that task in a list of tasks
• Changing a task to high priority in the task options window appends a double up arrow to a task

BUT ... manually appending a double up arrow to a task does not change the priority of a task in the way that other emojis like the single up arrow does.

Steps to reproduce

Create task with double up arrow manually appended to the end of a task Create a dataview listing of that task check the priority assigned

Which Operating Systems are you using?

• [ ] Android
• [ ] iPhone/iPad
• [ ] Linux
• [X] macOS
• [ ] Windows

Obsidian Version

1.4.13

Tasks Plugin Version

0.1.16

Checks

• [ ] I have tried it with all other plugins disabled and the error still occurs

Possible solution

No response

[claremacrae]

Thanks for using Tasks.

There is descriptive text in your report that is not provided as text for me to copy, so for reasons explained in the following post, I am unable to investigate:

https://publish.obsidian.md/tasks/Support+and+Help/Report+a+Bug

If you can provide full text, and full numbered steps for a reproduction, as per the above, I will willingly have a look when I have time.

Thank you.

[JasonBates]

Specific steps to create the error

1. Create a task, and type / append ⏫️ to the end of the task
2. open the 'Tasks: create or edit tasks' dialogue from the command palette
3. The priority of task is shown as 'normal' where it should be high

This is an anomoly, as if you use 🔼 or 🔽 at the end ofthe task, on opening the command palette and the tasks dialogue box, the task status is shown correctly as medium or low in the cases above.

[claremacrae]

1. I can reproduce it if I use the ⏫️ character from your message above.
2. If I use Tasks's Auto Suggest or its Edit task modal and add a High priority, and then copy that, it works

So the conclusion is that you are using an emoji which is similar in appearance to the one used by Tasks, but not the actual one it uses.

What did you do to obtain the Emoji you are using?

(Also, this is why we need to ask for precise steps to reproduce user feedback....)

[Cito]

Actually, the ⏫️ character used by @JasonBates is the right one. However, it is followed by an invisible so-called variant selector VS16 which essentially says that the preceding character should be interpreted as an emoji. It seems that Tasks gets confused by this modifier, and we should probably fix this.

[claremacrae]

Wow, thanks @Cito - how were you able to work this out? I have been hunting for a way on Mac to show the actual underlying characters, and not succeeded....

[claremacrae]

This may be useful, although it is a lot to take in: TR18: guidelines for how to adapt regular expression engines to use Unicode.

[JasonBates]

1. I can reproduce it if I use the ⏫️ character from your message above.
2. If I use Tasks's Auto Suggest or its Edit task modal and add a High priority, and then copy that, it works

So the conclusion is that you are using an emoji which is similar in appearance to the one used by Tasks, but not the actual one it uses.

What did you do to obtain the Emoji you are using?

(Also, this is why we need to ask for precise steps to reproduce user feedback....)

To create the emoji, I used ctrl + cmd + space on a Mac, and then selected the emoji from the selector.

It’s interesting was that this method works for the single up arrow and the single down arrow, changing the priority as expected, but doesn’t work for the double up arrow.

Thanks 🙏

[Cito]

I have been hunting for a way on Mac to show the actual underlying characters, and not succeeded....

You can copy&paste this into a string literal in a JavaScript or Python file and then examine it using charCodeAt() or ord().

Or you can use this very helpful online tool: https://apps.timwhitlock.info/unicode/inspect

[claremacrae]

I've added the 'help wanted' label to this. It's outside my zone.

[claremacrae]

This has just cost me half an hour, writing some tests for new code in Tasks!

[claremacrae]

Suggestion from @therden that calling string.normalize() may fix this: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize

[claremacrae]

Suggestion from @therden that calling string.normalize() may fix this: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize

The following has a variant selection in it:

                - [ ] Task being edited ⛔ 12345
                - [ ] Task being edited️ depends on this 🆔 12345
                - [ ] Is not depended on by the task being edited

I tried all these, one at a time, and for me, none of them removed the variant selector:

    const allTasks = createTasksFromMarkdown(markdown.normalize('NFC'), 'filename.md', 'header');
    const allTasks = createTasksFromMarkdown(markdown.normalize('NFD'), 'filename.md', 'header');
    const allTasks = createTasksFromMarkdown(markdown.normalize('NFKC'), 'filename.md', 'header');
    const allTasks = createTasksFromMarkdown(markdown.normalize('NFKD'), 'filename.md', 'header');

[claremacrae]

There's an interesting new issue related to this:

• https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2693

It's the opposite way round though. We have ended up with an emoji in the Tasks code that includes VS16 - and Tasks is failing to parse values from any lines that have the emoji without VS16 ⛔ - I am investigating.

[claremacrae]

Just released in Tasks 6.1.1.