#1

Steps to reproduce

In a note, on a new line, enter a tag name and immediately hit return, without typing a space at the end of the line.

E.g.:

#sometag

Expected result

I’d expect the line to consist of the tag I’d entered and nothing else, i.e. #sometag.

Actual result

Frequently/almost always (but with some exceptions I haven’t quite worked out), the line actually consists of the tag I’ve entered and an extra space at the end of the line, i.e. #sometag .

Environment

  • Operating system: MacOS 10.14.6
  • Obsidian version: 0.6.4
  • Using custom CSS: no

Additional information

I had initially thought that this only happens when the tag appears on its own, but that’s not true - it just seems to happen (almost every time, but with some exceptions) when the line ends with a tag.

I could ameliorate this problem by (say) adding a pre-commit hook to strip such trailing spaces automatically — but I really don’t want to do that of course, because in (at least some dialects of) markdown two trailing spaces have semantic content, namely a linebreak. As described in Feature Request 533 Obsidian’s behaviour around linebreaks is rather surprising, but I’m not ready to give up on the “standard” (such as it is) just yet.

Automatic space inserted after selecting tag
#2

I understand from your standpoint it seems like a bug, but it seems to be the conventional behavior, when you @ people on Twitter or Discord. It’s so that you can start entering the next tag or word.

If there’s no white-space after the tag, the tag is still not finished, and the autocomplete would still be visible, while you need to manually enter a space or newline to write something after the tag. Would that be your expected behavior?

1 Like
#3

Sorry for the delay in replying… This is really interesting, because it’s all about the autocomplete menu, which I hadn’t realised at all.

I was initially confused by your point about it entering a space “so you can start entering the next tag or word”, because to me, if I’ve hit return, I want a newline, so why would anyone want that? But then I realised that when a user chooses an existing tag from the autocomplete menu, that is indeed a helpful/sensible/conventional behaviour. OK.

However: I’m not doing that; I’m just typing a hashtag in full and hitting enter, and wanting Obsidian to just interpret that as me typing as normal. The problem is that if the hashtag I’m typing already exists, Obsidian pops up the autocomplete menu, and when I’ve typed the whole thing I now have an autocomplete menu with only one item in it, and hitting return is interpreted as choosing that one item - even though I didn’t interact with that menu at all. Notice that in my original bug report I didn’t even mention the autocomplete menu because I hadn’t even spotted that this was what was happening.

Also worth nothing: if I enter an entirely new hashtag, there’s no autocomplete menu by the time I’ve entered the whole hashtag, and Obsidian behaves as I’d expect and just enters a newline with no space.

So it seems to me there are two different modes here; “just typing a hashtag” and “typing a hashtag but then using the autocomplete menu”.

Perhaps the helpful space could only be entered in the second case, i.e. if the user actually interacted with the autocomplete menu using their arrow keys or by clicking on an item? That’s what happens now with completely new hashtags.

Another thought: what if the helpful space was only entered if the autocomplete menu had more than one item in it when the user hits return? As way to check the condition “user typed entire hashtag”, that’s possibly easier than tracking “did they hit the up/down arrows or click on the menu”, I guess.

And I get it if you don’t want to make these changes: I realise this is quite nit-picky and a corner case; but as you can see it was quite surprising to me at least.

Thanks!

#4