Incorrect priorities

[jubnzv]

Describe the bug

I found two minor issues when setting a priority to the item.

They are small and have the same scope, so I report them in the single issue.

If an org-mode item doesn't have a priority, you could try to set either an empty priority or just press a <Space> in priorities prompt. In these cases you'll get #[nil] and #[ ] priorities accordingly.

Steps to reproduce

1. Create a new org-mode element: * test1

2. Enter <leader>o, to open the priorities prompt

3. Just press Enter

4. You'll get #[nil]

5. Create a new org-mode element: * test2

6. Enter <leader>o, to open the priorities prompt

7. Enter (space) and press Enter

8. You'll get #[ ]

Expected behavior

In the both cases we shouldn't add a new priority at all.

Emacs functionality

No response

Minimal init.lua

It is reproducible with the suggested minimal_init.lua.

Screenshots and recordings

OS / Distro

Debian testing

Neovim version/commit

NVIM v0.8.0-dev+448-g7b2b44bce

Additional context

No response

[jgollenz]

Thanks @jubnzv, I can confirm this bug. It seems that one can also specify a priority that starts with one of the valid default letters we have for priorities. So abc, bar, ccccc will result in [#ABC], [#BAR] and [#CCCCC] respectively, but duh will result in [#nil].

[jgollenz]

In Emacs orgmode it's only possible to add a single character, no need to confirm with <CR>. If it's valid, this priority gets assigned. If it's invalid, nothing gets insert and the user gets informed that the priority must be between A and C. This might be different when the priorities are multi-character strings, which I'm not sure is possible (see here).

[jgollenz]

For the record, multi-character strings should™ be possible (according to this) IF one uses a numerical priority-scheme with more than nine states. See #382