I would like to disable the popup menu when a # without a space is typed on my instance of Discourse.
For example on meta it looks like the following:
I’d rather that popup not show up at all. I looked around for some options and was unable to identify a way to disable this.
Do you want to disable it completely? Or do you want to avoid it just in the case where no following character has been typed?
We used to wait until at least 1 character was added following the #, but have changed it so it no longer requires that (folks requested this in the past but we avoided it earlier for technical reasons that no longer apply).
Thank you for your quick response, ideally I can re-enable the previous behavior, which I assume means I’d have to type #c before I get a list of tags or categories that match that character. If that is difficult completely disabling the functionality is also a viable option but ideally not at the cost of getting rid of tags and categories all together.
Can you explain the benefit of waiting for a character before offering to autocomplete?
Sure. I find it distracting to be faced with a menu of categories when I am just typing up a header. This really is apparent with younger/slower authors. When they type # and then think about the header they want to write they are given this category menu that has nothing to do with what they are trying to type.
Yes “#<space>” stops it but it is distracting for that period of time when they find the space bar and confusing because the computer is suggesting something that might make sense when typing a comment but doesn’t really make sense when authoring a post and entering a heading.
Is that clear? Sorry I tried a couple of times to describe it but I am not sure I landed 
The correct markdown for a heading includes a space after the #. Have you considered using the space to dismiss it?
I am talking about the brief period of time between someone typing # and then hitting space.
Consider a hunt and peck typer, they hit # then look for the space and now they have a menu option that they need to make a decision around. Even if you type “#<space>” quickly it still shows up for a brief period, whereas before it was something one would have to intentionally type by using multiple letters e.g. “#c” to start a search / select of a tag.
What I am suggesting is that what is now a default behavior is distracting and breaks up the flow of editing rather than providing a short cut to a more used function than creating a header. I’ve witnessed this with some of our newer computer users but I also find it distracting because I am usually thinking about what to call my header and now I need to hit #<space> to work around a distracting menu I never use.
If I am in the minority I can look at patching it out but I was hoping for a config based option.
I wonder if we could ask for a config option - how many chars need to be typed before the autocomplete popup appears?
As # is used for markup as well as for ordinary human communication, having it pop something up too eagerly sounds like a usability - and perhaps accessibility - issue to me.
Thanks for calling this out.
I think something like this is a reasonable suggestion. Let me see what others think about this idea.
Given this context, perhaps it would make sense to consider making this a user preference rather than a site setting… 
How would you name this setting for younger/slower authors so they would immediately grasp what it does?
Also, I think that a lot of users don’t go into their settings except to fill in their user profile, I feel like the vast majority of users use forums software as it is, and wouldn’t even know that such an option may exist in their own settings (I’m one of this kind of guys 
).
Hmm, I don’t feel good about making accessibility an opt-in. I think the default should be accessible, both at site and user level.
I’m not sure I agree this is an accessibility problem (because there is no problem accessing any feature). I could agree to call it a (minor) usability issue, but I see it mostly as preference issue.
I’ve been scratching my head on the accessibility comment too.
Looking to other platforms there are those which offer tag suggestions the moment a # is entered - Twitter on iOS begins by offering trending tags until the user enters a second character.
I’m not sold on the hunt-and-peck angle either, by definition they’re looking down at their keys. If anything the tag popup serves as a reminder that the user is now in tag entry mode until they hit space.
What I like about the new behavior is how much more visible it makes tag entry to newcomers.
Headings can’t be entered unless they’re at the start of a new line, but would we want the default behavior changing based on cursor position? The one group who will be confused are touch typists who don’t know that the # for headings should be followed by a space.
So where did we land here? It is painfully obvious that while this does make tags more prominent it overloads an operator for typing in the editor in a way that I consider confusing and breaks up the user from the flow of editing their post.
This is a problem even when you aren’t adding new headers. Just use arrow to browse through a topic you already edited that has headings anywhere. You arrow down to a # and then when you keep hitting the arrow it starts to select a particular tag or category rather than continuing down the page with your cursor. I now have to hit escape to continue to move down in the post with the keyboard or avoid # landmines.
Edit a post with the two examples above and use the arrow to go around and you’ll see exactly what I mean. I agree it makes tags more prominent but if you don’t use tags that is not a feature it is something new in the way of what you used to do.
As far as younger editors. Having their editor do magical things when they are just trying to grok creating headers with markdown language is overloading the user with more things they don’t need to know or understand.
It is fine if the decision is to do nothing here, i’ll look into figuring out a way to just patch it out but given the break up of editing flow and the curve we are adding to new users to have to understand more than what’s in front of them it seems like an option is a good compromise. I’d take at the site level cause likely if you use tags that is more a site decision rather than a per user decision but per user based on site default is probably the way to go.
mr. Jobs was then right indeed when he said that cursors are useless
Just kidding.
But I’m using cursor keys all the time because I do a lot writing, mostly longer texts, and I don’t recoqnize situation you are describing.
(Edit: I came up here dodging every mines 
)
and not even here and now
I can use tags using hash-autocompletion because this new system so nicely works how-to or just typing one if I can remember it: unsupported-install — that worked too.
So — what I don’t understand now?
At this time, we don’t have any plans to make any specific changes here.
I’m not sure the best fix for this and it seems a bit unlikely to happen, but I can reproduce this by parking my cursor in the right place and I agree it is annoying when it does happen (when the cursor is 1 character in from the beginning of the line).
I appreciate the update and how @mcwumbly captured the current state. Thank you, @mcwumbly, for taking the time to also create the animated examples! There is nothing else open from my end.
The fix to me is simply disabling autocomplete for hashtag
So
#
Would not issue autocomplete
test #
Would issue autocomplete
#t
Would issue autocomplete
By adding these rules all the cursor shenanigans would no longer happen and user impact would be absolutely minimal.
@martin … thoughts?
Just a reminder that there were some topics with people (me included) asking for the current behavior before, when it was exactly like the described.