Hey wonderful discourse maintainers,
I was wondering if there was a policy about enabling the tab key when editing markdown. I was recently composing a list and I wanted to indent, so I hit enter, tab, -, and then space, which triggered the “reply to topic” action unintentionally.
It would be fantastic if users could set a preference to enable the tab key inside text editors.
I’m sorry if this has been discussed before. What do people think?
Hmm, I’m pretty sure that this would hurt accessibility, but it might be a good idea… We already have Ctrl-Enter to submit.
Tab is expected to move from field to field, so this would seriously hurt keyboard accessibility and standard browser conventions.
Yeah, I totally understand that this would be non-standard behavior and less accessible. The right solution, I think, would be to enable it only by user opt-in.
I can’t even do it in GMail. 
I was thinking something like CTRL+TAB which you would use in Excel, but I’m not finding any online composers that permit this behavior…
In Chrome CTRL TAB takes you to the next… tab.
I think it’s been a poor choice of using the Tab key to move to the next field. But now we have to keep it, it’s too late.
That is browser design 101… You will find that was happening well back in IE 6. So that isn’t a Discourse only issue.
Tab was used to iterate from field to field for as long as I can remember in computer GUIs.
Per Wikipedia, tab as a key to move from field to field in a GUI dates back to at least 1987.
As we all know, when working in a desktop editor, the tab always adds spaces. The problem is the choice of using the same key (tab) to do two completely different things.
Try it in Notepad 
This has always bugged me. And I realize it’s not specific to Discourse. But it’s my understanding that Discourse is about ‘reimagining what a modern Internet discussion platform should be today’.
I’m wondering how other people handle it. I fully understand and appreciate the browser convention. This doesn’t change the fact that tab is valid content. Also, it’s preserved when copying and pasting content into the editor. I see it as 2 separate but overlapping issues.
The browser convention issue is resolved with…
But that leaves the content issue.
I’m not bringing this up just to be pedantic. I’m playing around with Discourse as a place to post code and markup snippets and this is something that does come up.
Cheers
Never gonna happen on my watch. Tab means move to next field in the browser, always has, always will.
this is a very old topic, so maybe there’s fresh stuff going on, but I’m with Jeff on ‘tab’ meaning field to field. so I came here to ask how I can change this:
tab followed by enter leads to posting the topic/reply.
which is seriously inconvenient in my case. Any suggestions on how I can stop that? thanks!
텍스트 한 줄을 선택한 뒤 Tab 키를 누르면 들여쓰기가 된다는 걸 방금 알게 되었어요. 꽤 좋은 절충안이네요!
물론 여러 줄을 선택해도 마찬가지입니다.
정말 그렇습니다! @martin이 얼마 전에 추가한 멋진 작은 기능이죠.
탭을 들여쓰기에 사용할 수 있으면 좋겠습니다.
구현이 너무 복잡하지 않기를 바랍니다.
이것은 분명히 Markdown에 의해 제한되는 것인가요?
Markdown에서는 이중 공백을 사용하여 항목 들여쓰기를 표시합니다.
공백은 다음을 관리하는 데 사용됩니다:
대부분의 마크다운 에디터에서는 탭(Tab)과 시프트+탭(Shift+Tab) 키를 사용하여 다음(또는 이전) 레벨로 이동할 수 있습니다.
현재 탭 키를 누르면 작성창에서 나가게 되는데, 이 부분은 더 잘 처리할 수 있지 않나요?
여기 Discourse에서 정말 유용할 것 같아요.
왜 안 되는지 늘 궁금했거든요.
Word Perfect, Pagemaker, MS Word 같은 워드 프로세싱 프로그램에서는 타자기의 기능처럼 들여쓰기를 수행합니다. 물론 ‘컴포저(편집 영역)’ 밖으로 나가면 말씀하신 대로 동작합니다. 하지만 워드 프로세서의 컴포저 창 안에서 문서를 작성하고 있을 때는 들여쓰기 기능으로 작동합니다.
위키의 정신에 맞게 
Tab key - Simple English Wikipedia, the free encyclopedia(short%20for,to%20the%20next%20tab%20stop.&text=In%20word%20processor%20applications%2C%20the,to%20the%20next%20tab%20stop.
컴포저 안에서는 워드 프로세싱 환경의 창 안에 있는 것입니다.
맞는 말씀이네요. 탭 키로 공백을 입력할 수 없는 이유가 뭐죠?
