Text properties not applied to hidden buffers when 'nohidden' is used

[nickspoons]

Describe the bug
When set nohidden is used and a text property is applied to a hidden buffer, the text property is not persisted and various errors can occur. There is no mention of 'hidden' in textprop.txt.

To Reproduce

1. Run echo 'a' > a ; echo 'b' > b ; vim --clean a b
2. :set nohidden
3. :call prop_type_add('ErrorMsg', #{highlight:'ErrorMsg'})
4. Highlight buffer 1:
   :call prop_add(1, 1, #{end_lnum:1,end_col:2,type:'ErrorMsg',bufnr:1})
5. a is highlighted
6. :next
7. :prev
8. a is no longer highlighted
9. Highlight buffer 2:
   :call prop_add(1, 1, #{end_lnum:1,end_col:2,type:'ErrorMsg',bufnr:2})
10. :next
11. The buffer is empty
12. :e
13. The buffer is now populated with b again

Expected behavior
At step 8. above, I expected the text properties to be retained for the buffer, after navigating away and back again. If set hidden is used, the text properties are retained.

At step 11., something has clearly gone wrong - the contents of the buffer are missing.

Further bugs: To Reproduce

1. Run echo 'a' > a ; echo 'bbb\nbbb\nbbb' > b ; vim --clean a b
2. :set nohidden
3. :call prop_type_add('ErrorMsg', #{highlight:'ErrorMsg'})
4. Highlight buffer 2:
   :call prop_add(1, 2, #{end_lnum:2,end_col:2,type:'ErrorMsg',bufnr:2})
5. E966: Invalid line number: 2

Expected behavior
Buffer 2 has 3 lines so this should be fine, but an error is reported.

Environment (please complete the following information):
Tested in arch linux terminal Vim 8.1.1839 (built from git) and Windows 10 gVim 8.1.1839 (from vim-win32-installer)

[brammool]

**Describe the bug** When `set nohidden` is used and a text property is applied to a hidden buffer, the text property is not persisted and various errors can occur. There is no mention of `'hidden'` in `textprop.txt`. **To Reproduce** 1. Run `echo 'a' > a ; echo 'b' > b ; vim --clean a b` 2. `:set nohidden` 3. `:call prop_type_add('ErrorMsg', #{highlight:'ErrorMsg'})` 4. Highlight buffer 1: `:call prop_add(1, 1, #{end_lnum:1,end_col:2,type:'ErrorMsg',bufnr:1})` 5. `a` is highlighted 6. `:next` 7. `:prev` 8. `a` is no longer highlighted 9. Highlight buffer 2: `:call prop_add(1, 1, #{end_lnum:1,end_col:2,type:'ErrorMsg',bufnr:2})` 10. `:next` 11. The buffer is empty 12. `:e` 13. The buffer is now populated with `b` again **Expected behavior** At step 8. above, I expected the text properties to be retained for the buffer, after navigating away and back again. If `set hidden` is used, the text properties are retained.

That is intented. Perhaps the documentation should be clearer: The text properties are stored with the text, thus if you drop the text (unload the buffer), the text properties are gone.

At step 11., something has clearly gone wrong - the contents of the buffer are missing.

Yes, that is a bug.

**Further bugs: To Reproduce** 1. Run `echo 'a' > a ; echo 'bbb\nbbb\nbbb' > b ; vim --clean a b` 2. `:set nohidden` 3. `:call prop_type_add('ErrorMsg', #{highlight:'ErrorMsg'})` 4. Highlight buffer 2: `:call prop_add(1, 2, #{end_lnum:2,end_col:2,type:'ErrorMsg',bufnr:2})` 5. `E966: Invalid line number: 2` **Expected behavior** Buffer 2 has 3 lines so this should be fine, but an error is reported.

Buffer 2 is not loaded, thus has no lines at all. Same problem as the previous bug.

**Environment (please complete the following information):** Tested in arch linux terminal Vim 8.1.1839 (built from git) and Windows 10 gVim 8.1.1839 (from [vim-win32-installer](https://github.com/vim/vim-win32-installer/releases))

I have made a fix.

…

-- hundred-and-one symptoms of being an internet addict: 51. You put a pillow case over your laptop so your lover doesn't see it while you are pretending to catch your breath. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[nickspoons]

Thanks very much Bram, this is much better, consistent with a very clear error message.