Discourse 인스턴스에서 # 뒤에 공백 없이 입력할 때 팝업 메뉴를 비활성화하고 싶습니다.
예를 들어, meta에서는 다음과 같이 표시됩니다:
저는 이 팝업이 아예 표시되지 않는 것을 선호합니다. 여러 옵션을 찾아보았지만 이를 비활성화하는 방법을 찾지 못했습니다.
3개의 좋아요
완전히 비활성화하시겠습니까? 아니면 뒤에 아무 문자도 입력되지 않은 경우에만 피하는 것이 좋을까요?
이전에는 # 뒤에 최소 1개의 문자가 추가될 때까지 기다렸지만, 이제 더 이상 그렇게 하지 않습니다. (과거에 사용자들께서 이 기능을 요청하셨지만, 당시에는 더 이상 해당되지 않는 기술적 이유로 인해 적용을 보류했습니다.)
6개의 좋아요
빠른 답변 감사합니다. 이상적으로는 이전 동작을 다시 활성화할 수 있었으면 하는데, 그렇게 하려면 태그나 카테고리가 그 문자와 일치하는 목록을 받기 전에 #c를 입력해야 한다는 걸로 이해하고 있습니다. 만약 그것이 어렵다면 해당 기능을 완전히 비활성화하는 것도 대안이 될 수 있지만, 가능하면 태그와 카테고리를 아예 없애는 것까지는 피하고 싶습니다.
1개의 좋아요
자동완성을 제안하기 전에 한 글자를 기다리는 것의 이점을 설명해 줄 수 있나요?
6개의 좋아요
네. 단순히 헤더를 입력하려는데 카테고리 메뉴가 뜨면 집중이 산만해집니다. 특히 어린 작가나 타이핑 속도가 느린 사람들에게서 이런 문제가 더 두드러집니다. 헤더를 입력하기 위해 #을 치고 나서 어떤 헤더를 쓸지 생각하다가, 그들이 입력하려는 내용과 전혀 관련이 없는 카테고리 메뉴가 뜨게 되거든요.
물론 "#"를 입력하면 메뉴가 사라지긴 하지만, 스페이스바를 찾는 그 짧은 순간에도 산만해지고, 컴퓨터가 코멘트를 작성할 때는 그럴듯해 보이지만 포스트를 작성하면서 헤더를 입력할 때는 별로 의미가 없는 제안을 하고 있어서 혼란스럽습니다.
이해가 되시나요? 몇 번이나 설명을 시도해 봤는데 제 말이 제대로 전달됐는지 모르겠네요 
2개의 좋아요
헤딩에 사용되는 올바른 마크다운 형식은 # 뒤에 공백을 포함해야 합니다. 이 공백을 이용해 헤딩을 무시하도록 하는 방법은 고려해 보셨나요?
2개의 좋아요
제가 말씀드리는 것은 누군가가 #을 입력한 후 공백을 누르기까지의 짧은 시간 구간입니다.
한 글자씩 확인하며 타이핑하는 사람을 생각해 보세요. #을 누른 뒤 공백 키를 찾아야 하는데, 이때 의사결정이 필요한 메뉴 옵션이 나타납니다. "#"를 빠르게 입력하더라도 여전히 짧은 시간 동안 표시됩니다. 이전에는 여러 글자를 의도적으로 입력해야 했기 때문에, 예를 들어 "#c"를 입력하여 태그 검색/선택을 시작하는 식이었습니다.
제가 제안하는 것은, 현재 기본 동작이 편집 흐름을 끊고 집중을 흐트러뜨리며, 헤더 생성보다 더 자주 사용되는 기능에 대한 단축키 역할을 하지 못하고 있다는 것입니다. 새로운 컴퓨터 사용자에게서 이를 목격했을 뿐만 아니라, 저는 헤더 이름을 무엇으로 할지 고민하고 있을 때 #를 눌러 사용하지도 않는 방해가 되는 메뉴를 우회해야 하므로 저도 집중이 흐트러집니다.
소수 의견이라면 패치를 적용해 제거할 수 있지만, 설정 기반의 옵션이 제공되기를 희망합니다.
1개의 좋아요
자동완성 팝업이 표시되기 전에 몇 자를 입력해야 하는지 설정 옵션을 요청할 수 있을까요?
기호는 마크업 용도로도 사용되지만, 일상적인 대화에서도 사용되므로, 너무 성급하게 팝업이 표시되면 사용성 — 어쩌면 접근성 — 문제라고 생각합니다.
2개의 좋아요
이 문제를 지적해 주셔서 감사합니다.
이런 제안은 합리적이라고 생각합니다. 이 아이디어에 대해 다른 분들이 어떻게 생각하시는지 한번 확인해 보겠습니다.
2개의 좋아요
이러한 맥락을 고려할 때, 이 설정을 사이트 설정이 아닌 사용자 설정으로 만드는 것이 더 합리적일 수도 있습니다… 
이 설정을 초보자나 느린 사용자들도 바로 용도를 파악할 수 있도록 어떻게 이름 붙일 수 있을까요?
또한, 많은 사용자가 프로필 입력 외에는 설정에 들어가지 않는다고 생각합니다. 대부분의 사용자는 포럼 소프트웨어를 있는 그대로 사용하며, 설정에 이런 옵션이 존재하는지조차 모를 가능성이 큽니다(저도 그런 사람 중 하나입니다 
).
3개의 좋아요
음, 접근성을 선택 사항(opt-in)으로 만드는 건 별로 좋은 생각이 안 들어요. 사이트 레벨이든 사용자 레벨이든 기본값은 접근성이 보장되어야 한다고 생각해요.
1개의 좋아요
이것이 접근성 문제라고 동의하기 어렵습니다(모든 기능을 접근하는 데 문제가 없으므로). (경미한) 사용성 문제라고 불러도 좋다는 데는 동의할 수 있지만, 저는 이 문제를 대부분 개인 취향의 차이로 봅니다.
4개의 좋아요
접근성 관련 코멘트도 나도 좀 고민이 많았습니다.
다른 플랫폼을 보면 #을 입력하는 순간 태그를 제안하는 경우가 있습니다. iOS의 Twitter는 사용자가 두 번째 문자를 입력할 때까지 트렌딩 태그를 먼저 제안합니다.
키를 하나씩 찾아 치는(hunt-and-peck) 방식이라는 점에도 동의하기 어렵습니다. 정의상 그런 사용자는 키보드 아래를 보고 있기 때문입니다. 오히려 태그 팝업은 사용자가 스페이스바를 누를 때까지 태그 입력 모드에 있다는 것을 상기시켜 주는 역할을 한다고 봅니다.
새로운 동작 방식에서 마음에 드는 점은, 태그 입력이 신규 사용자에게 훨씬 더 잘 보인다는 것입니다.
제목은 새 줄의 시작 부분에 있을 때만 입력할 수 있지만, 커서 위치에 따라 기본 동작을 변경하는 것이 좋을까요? 혼란을 겪을 유일한 그룹은 제목의 # 뒤에 스페이스바를 따라야 한다는 것을 모르는 타이핑 숙련자일 것입니다.
4개의 좋아요
결국 지금 우리는 어디에 와 있는 걸까요? 태그를 더 눈에 띄게 만들기는 하지만, 에디터에서 타이핑할 때 특정 연산자를 오버로드하는 방식은 혼란스럽다고 느끼며, 사용자가 게시물을 편집하는 흐름을 끊어 버린다는 점이 아픈 손가락처럼 분명합니다.
새로운 헤더를 추가하지 않을 때도 이 문제는 발생합니다. 이미 편집한 주제에서 헤더가 어디에 있는지 확인하기 위해 화살표 키를 사용해 둘러보세요. # 기호까지 아래로 이동한 뒤, 계속 화살표 키를 누르면 커서가 페이지를 계속 아래로 이동하는 대신 특정 태그나 카테고리를 선택하기 시작합니다. 이제 키보드로 게시물을 계속 아래로 이동하려면 Esc 키를 눌러야 하거나 # 지뢰를 피해야 합니다.
헤더 1, 커서가 파운드 기호 근처에 오지 않도록 하세요.
헤더 2, 커서가 첫 번째 # 앞에 오면 메뉴가 표시됩니다.
위 두 예시로 된 게시물을 편집하고 화살표 키를 사용해 여기저기 이동해 보면 제가 무슨 뜻인지 정확히 아실 겁니다. 태그가 더 눈에 띄게 된다는 점에는 동의하지만, 태그를 사용하지 않는다면 그것은 기능이 아니라 과거의 작업 방식에 새로 추가된 것입니다.
젊은 편집자들의 경우, 마크다운 언어로 헤더를 만드는 것을 파악하려는 중에 에디터가 마법 같은 행동을 하는 것은 사용자가 알거나 이해할 필요가 없는 것들로 사용자를 과부하 시키는 것입니다.
여기서 아무것도 하지 않기로 결정하는 것도 괜찮습니다. 그냥 패치해서 제거하는 방법을 찾아볼 테지만, 편집 흐름이 끊어지는 점과新用户들이 눈앞에 있는 것보다 더 많은 것을 이해해야 하는 학습 곡선을 추가하는 점을 고려하면, 옵션을 제공하는 것이 좋은 타협점이 될 것 같습니다. 사이트 레벨에서 설정하는 것이 좋겠습니다. 태그를 사용하는 것은 사용자별 결정보다는 사이트 결정에 더 가까울 가능성이 높기 때문입니다. 하지만 사이트 기본값을 기준으로 사용자별로 설정하는 것이 아마도 가장 좋은 방법일 것입니다.
2개의 좋아요
조布斯 선배가 커서는 쓸모없다고 하셨을 때, 그분은 정말로 옳으셨네요
농담입니다.
하지만 저는 긴 글을 많이 작성하기 때문에 커서 키를 항상 사용하고 있습니다. 그리고 여러분이 설명하시는 상황을 이해하지 못하겠습니다.
(편집: 지뢰를 모두 피하면서 여기까지 올라왔습니다 
)
두 번째 수준 헤더
그리고 지금 여기에서도
세 번째 수준: 태그
이 새로운 시스템이 정말 잘 작동하기 때문에 해시 자동완성을 이용해 태그를 사용할 수 있습니다. how-to 또는 기억나면 그냥 입력하는 것도 가능합니다: unsupported-install — 이 방법도 잘 작동했습니다.
그러니 — 지금 제가 이해하지 못하는 것은 무엇일까요?
현재 이 부분에 대해 특정 변경 사항을 도입할 계획은 없습니다.
이 문제에 대한 최선의 해결책이 무엇인지는 확실하지 않고, 이런 상황이 발생하는 것은 다소 가능성이 낮아 보이지만, 커서를 적절한 위치에 놓으면 재현할 수 있으며, 실제로 발생할 때(커서가 줄의 시작에서 1자 안에 있을 때) 귀찮다는 데에는 동의합니다.
커서가 줄의 시작에 있는 경우
커서가 줄의 시작에서 1자 안쪽에 있는 경우
커서가 2자 안쪽에 있는 경우
5개의 좋아요
업데이트와 @mcwumbly 님이 현재 상태를 잘 담아주신 점에 감사드립니다. @mcwumbly 님, 애니메이션 예제까지 직접 만들어주셔서 정말 감사합니다. 제 쪽에서 더 이상 처리할 사항이 없습니다.
1개의 좋아요
제 생각에는 해시태그에 대한 자동완성을 단순히 비활성화하는 것이 해결책입니다.
즉,
#
은 자동완성을 트리거하지 않습니다.
test #
은 자동완성을 트리거합니다.
#t
은 자동완성을 트리거합니다.
이 규칙들을 추가하면 커서 관련 문제가 더 이상 발생하지 않고, 사용자에 미치는 영향은 거의 없을 것입니다.
@martin … 의견이 있으신가요?
2개의 좋아요
이전에 설명된 것과 완전히 똑같았을 때, 현재 동작에 대해 질문을 하던 몇 가지 주제(나도 포함)가 있었음을 상기시켜 드립니다.
1개의 좋아요