인용문 컨텍스트가 인용 기능에 영향을 줍니다

제품 지원
1

인용 구문을 잘못 편집하여 인용 기능이 실패하는 사용자가 있습니다. 예를 들어, 현재 주제에서 발견한 아래 예시를 살펴보겠습니다. 이는 이스케이프되지 않은 상태입니다:

[quote=“CFO.Digest.Input, post:1, topic:3258”]
he suggested that I put mineral oil back in. [/quote]

문제는 시작 태그가 단독 줄에 있는 반면, 종료 태그인 /quote가 텍스트 스트림 안에 있다는 점입니다. 두 가지 방식 모두 사용할 수 있지만, 반드시 일치해야 한다는 것을 발견했습니다. 예를 들어, 아래처럼 동작합니다(함수를 이스케이프하기 위해 '를 추가했습니다):

'[quote=“CFO.Digest.Input, post:1, topic:3258”]
he suggested that I put mineral oil back in.
'[/quote]

그리고 이 방식도 동작합니다:

'[quote=“CFO.Digest.Input, post:1, topic:3258”]he suggested that I put mineral oil back in.[/quote]

… 하지만 두 방식을 섞어 사용할 수는 없습니다.

“그렇게 하지 마세요” 또는 "인용 버튼을 사용하세요"라고 말하는 사람이 있을 것임을 압니다. 하지만 여전히 올바르게 하지 않는 사용자가 있습니다.

두 방식을 섞어 사용할 수 있도록 파싱할 방법이 없을까요?

2

몇 년 전 의도적으로 변경된 사항입니다:

3

아니… 그렇다면 우리는 기본적으로 고객과 사용자에게 코딩 표준을 강제하는 건가요?

샘의 포맷 분석에는 동의하지만, 작성자가 읽기 어려운 것과 게시물을 보는 모든 사람이 읽기 어려운 것 사이에는 차이가 있습니다. 뭔가 작성자의 잘못 때문에 독자를 벌주고 있는 것 같은데요…

글을 엉망으로 만든 사람들을 보면 계속 수정을 해야 할 것 같습니다.

수정: 또 다른 옵션은 [/quote] 뒤에 줄바꿈이 없다면 강제로 줄바꿈을 넣는 것입니다… 가독성을 위해 포맷을 자동으로 수정하는 거죠.

4

나쁜 아이디어는 아닌 것 같은데, 텍스트를 선택하고 인용 버튼을 사용하는 경우에는 작동하거든요. 다시 돌아가서 인용 부분을 편집하면서 포맷을 깨뜨리는 건가요?

5

네, 맞아요! 정말 놀랍긴 하네요… 그런데 그 과정에서 포맷을 깨고 있다는 걸 알아채지 못했네요. 아마 미리보기 기능을 켜지 않은 걸까요? 아니면 모바일로 작업 중일 수도 있고요…

그리고 이걸 한 사람은 이 사업의 핵심 원칙 중 하나를 맡고 있는 사람인데… 정말 다행히도 그분을 에디터로 만들지 않았네요! :slight_smile:

6

아하! 모바일이 좋은 선택이네요. 딱 맞는 것을 고르는 것도 쉽지 않고, 그러면 어설프게 다듬다가 '수정’하려고 할 때 미리보기조차 없게 될 수 있으니까요.

7

이 문제는 내 시스템에서 여전히 반복적으로 발생하고 있습니다. 오늘 다음과 같은 메시지가 표시되었습니다:

image
image565×145 11.1 KB

닫는 인용 태그 뒤에 개행 문자(carriage return)를 추가하여 게시물을 수정했지만, 줄바꿈 문자와 개행 문자가 태그의 기능에 영향을 주지 않는 HTML처럼 텍스트 스트림이 파싱되지 않는다는 점은 여전히 놀랍습니다. 버그인 것 같습니다…

8

아니요, 태그는 그렇게 작동합니다. 태그를 아무렇게나 무작위로 삽입한다고 해서 정상적으로 동작한다고 기대할 수는 없어요.

9

순서가 무작위인 것은 아니고, 그냥 괜찮은 것입니다. 하지만 HTML과 달리 이 시스템에서는 줄바꿈이 어디에 위치하는지가 중요합니다.

깨진 게시물을 수정하기 위해 닫는 태그 뒤에 줄바꿈/CR을 추가하는 것만으로 충분했습니다.

사용자가 요구되는 구조를 따르지 않을 때 게시물을 수동으로 편집하는 것은 기꺼이 할 수 있지만, 줄바꿈이 파서에 영향을 미친다는 사실은 여전히 이상하게 느껴집니다…

10

마크다운 스펙을 한번 살펴보세요. HTML과 달리 마크다운은 잘 배치된 줄바꿈에 완전히 의존합니다.

<h1> 요소에 실수로 줄바꿈이 들어가도 렌더링에는 아무런 영향이 없겠지만:

여기는 마크

다운 세계에서는 영향이 있습니다

많은 요소에서 이것이 사실이며, 마크다운 테이블은 추가적인 줄바꿈으로 인해 심각하게 깨집니다. 반면 HTML 테이블은 그렇지 않습니다.

HTML 비유가 정확하거나 유용한지 확신이 서지 않습니다. 사용자에게 HTML을 작성하라고 요구하는 것이 아니기 때문입니다. <p></p>와 <br>가 누락되었을 때의 고통을 상상해 볼 수 있나요? 문자 그대로 벽이 생기거나 텍스트가 끊어집니다.

Discourse가 실제로 그렇지는 않지만 "마크다운 우선"이라고 생각한다면, 구조를 무시하고 태그를 던져 넣을 때 발생하는 문제들이 이해되기 시작할 것입니다.

11

저는 어떤 개발자처럼 이 복잡한 상황을 헤쳐 나가는 데는 문제가 없습니다. 하지만 우리의 사용자는 일반 시민들이며, 마크다운이 월마트의 가격과 관련이 있다고 생각할 수 있습니다.

말씀하신 대로, 다행히도 그들에게 HTML을 직접 작성하라고 요구하지는 않습니다! 마크다운 포맷을 구현하도록 강제하는 것이 어떤 이점을 가져다줄까요? 코딩 측면에서 아주 작은 정교함이 있다면, 사용자들이 이 현실의 복잡성으로부터 보호받을 수 있을 것 같습니다.

12

[/quote] 뒤에 자동으로 새 줄을 강제하는 것이 얼마나 복잡한지 모르겠습니다(코드 블록이나 비슷한 경우를 제외하고는 말이죠…). 마크다운을 사용할 때 지켜야 할 구조가 있다는 것도 이해합니다.

하지만 [/quote]와 같은 줄에 텍스트를 작성하는 것이야말로 그런 미미한 “실수”(그걸 실수라고 부를 수 있을지 모르겠지만) 때문에 잘못된 인용문이 사용자 메시지에 나타나는 것이 얼마나 짜증나는지 저도 충분히 이해합니다.
[quote]와 같은 줄에 텍스트를 작성하는 의도적인 경우가 있을까요?
만약 그런 경우가 없다면, 텍스트가 같은 줄에 존재할 이유가 전혀 없다고 생각합니다. 그리고 닫는 인용 태그 뒤에 새 줄을 강제하는 것은 사용자와 스태프 모두에게 이롭습니다. 하지만 이것이 보이는 것만큼 간단하지 않다는 것도 잘 알고 있습니다.

13

맞습니다. 마크다운의 기본 성질은 줄바꿈(또는 두 번의 줄바꿈)이 단락 태그와 동일하다는 것입니다. 이 때문에 일부 태그는 올바르게 해석되려면 앞이나 뒤에 줄바꿈이 필요합니다. 제 생각에는 이것이 명세(spec)의 일부입니다.