새 리치 텍스트 편집기에서 탈출된 틸드가 버그가 있습니다

구분 문자가 포함된 단락을 작성할 때, 이후에 입력하는 구분 문자가 의도대로 동작하지 않습니다. 구체적으로, 구분 문자(`)를 사용합니다와 같은 텍스트가 있는 상태에서, 같은 단락의 뒤에 ` 키를 다시 누르면 인라인 코드 스팬이 토글됩니다.

전역 문자가 포함된 `도 문제가 됩니다.

다음 내용을 리치 텍스트 편집기에 복사하여 붙여넣으면 재현할 수 있습니다:

Specifically, if I have some text that `` uses a ` (tilde) `` like this,
then pressing the <kbd>\`</kbd> key again later in the same paragraph
causes the inline code span to toggle about.

The escaped \` is also problematic.
1개의 좋아요

이건 좀 까다로운 문제입니다. 제가 보기에는 \ 에는 특별한 의미론적 처리가 적용되지 않는 것 같고, 왕복 과정에서 단순히 \\\ 로 변환되는 것뿐입니다.

@renato 님이 이 부분에 대해 몇 가지 아이디어를 가지고 있을 수도 있겠네요. 흥미로운 경계 사례입니다.

1개의 좋아요

이 문제는 이제 수정되었을 것입니다. latest(예: Meta/Try)를 실행하여 이 문제를 여전히 재현할 수 있습니까?

2개의 좋아요
\` 는 여전히 나에게 좀 이상하게 동작합니다. 특히 \` 가 \\\` 로 변하고, 그러면 추가적인 ` 이 생기는 순간 스태프가 닫혀버립니다.

전체적으로 해결하기가 정말 까다로운 문제인 것 같습니다.

미안하지만, 잘 모르겠어요. 리치 에디터에서 직접 입력할 때 \`는 이스케이프 처리되지 않아야 합니다.

마크다운 형식으로

\`hello

을 입력한 후, 리치 텍스트 모드로 전환하여

` 

을 입력합니다.

이렇게 하면 코드 블록이 생성되며, 기술적으로는 다음과 같이 렌더링되어야 합니다.

`hello`

2개의 좋아요

이것은 의도된 동작입니다. 마크다운에서 리치 텍스트로 전환되어 파싱될 때 이스케이프가 사라지며, 이는 \를 사용한 이스케이프가 마크다운/코드 개념이기 때문에 예상되는 결과입니다.

리치 에디터 모드에서 지원되는 이스케이프 방법은 입력 규칙이 적용된 후 백스페이스를 사용하는 것입니다: \like this`.

1개의 좋아요

아, 알겠어요. 설명해 주셔서 감사합니다.

1개의 좋아요

네, 조금은 나아졌지만, 여전히 인라인 코드 안에 `` 가 포함된 코드를 작성하려면 처음에 잘못 입력한 뒤 손질을 해야 하는 상황이 발생하기 때문에 사실상 불가능합니다. 사전에 ` `` 를 여러 개 사용할 수도 없습니다. 위에서 언급한 <kbd>\ 를 입력하거나 이를 생성하는 이스케이프 코드(<kbd>\`</kbd>)를 입력하는 것은 WYSIWYG 모드에서 손질을 하더라도 거의 불가능한 일들의 완벽한 예시입니다.

포맷팅을 되돌리려면 백스페이스를 눌러서 포맷팅을 취소하고 암묵적으로 "이스케이프"할 수 있다는 점은 이해합니다. 하지만 포맷팅이 언제 적용될지 예측하기가 어렵습니다. 예를 들어, `` 로 시작하는 ` 4*5*6 `` 은 자연스럽게 입력할 수 있지만, 항상 그런 것은 아닙니다. 4*5*6=120 은 잘 입력되지만 120=456 은 그렇지 않습니다(여기서 5가 일시적으로 이탤릭체로 표시되었습니다).

이러한 특정 사례에서 어떻게 해야 한다고 제안하시나요? 우리가 참고할 수 있는 방식으로 처리하는 다른 제품의 예시가 있으신가요?

\를 입력한 뒤 선택하고, ` 또는 cmd+E를 입력하여 인라인 마크로 전환할 수 있습니다.

cmd+E를 누른 다음에 \를 입력할 수도 있습니다. 굵게(cmd+B)나 이탤릭(cmd+E) 마크와 마찬가지로, 타이핑할 때 cmd+E를 사용하여 다음 문자의 코드 마크를 전환할 수 있습니다.

<kbd> 입력 규칙은 빈 문자를 자동 선택합니다(브라우저가 빈 노드를 자동으로 삭제하는 것을 방지하기 위함). 따라서 먼저 선택을 해제해야 합니다. 이 경우 \를 누르면 선택된 부분에 인라인 마크가 적용되므로(다만 cmd+E가 이 역할을 수행하므로 이 동작을 제거할 수도 있습니다).

이 방법들이 이상적이지 않을 수 있다는 점은 이해합니다. 하지만 Discourse 내부의 다양한 특수성 때문에 우리가 취할 수밖에 없는 절충안입니다. 다른 방식으로 작동하기를 원하신다면, 그 방법에 대한 제안을 환영합니다.

글쎄요, WYSIWYG 편집기를 활성화하면 마크다운 편집기가 단일 스페이스(monospace)로 바뀔 것 같아 보여서 이 주제를 열었습니다 (참고: Monospace font in the Markdown-only editor - #58 by mbauman ). 더 이상 그런 일이 없게 되어 정말 기쁘고, 이제 설정이 가능해져서 좋습니다. 네, 제가 마크다운 WYSIWYG 편집기를 좋아하는 적이 한 번도 없었거든요. 하지만 점점 좋아지고 있긴 합니다. :slight_smile:

저는 렌더링된 맥락과 렌더링되지 않은 맥락 모두에서 많은 텍스트 박스에 많은 양의 마크다운을 작성합니다(렌더링되지 않은 마크다운조차 “포맷된” 것으로 간주할 정도입니다). 제 경우는 꽤나 이례적이죠. 하지만 비슷한 ‘이례적인’ 사용자들의 집단이 존재한다고 생각하며, 우리는 주로 프로그래밍 언어 포럼에서 모이는 경향이 있습니다.

가장 가치 있는 부분은 자동 포맷팅을 최대한 예측 가능하게 만드는 것입니다. 그래야 백스페이스를 누를 때를 배울 수 있거든요. 하지만 제 경험상 그걸 배우기는 꽤나 어렵습니다.