우선, 훌륭하고 가치 있으며 유연하고 (대부분) 직관적인 도구로 평가되는 디스코urs를 만들어 주셔서 감사합니다. 저희는 사용자 기반 커뮤니티 토론 메일링 리스트부터 스크립트로 생성되어 주요 이벤트(새로운 이슈, 테스트 실패 등)를 알려주는 이메일까지, 프로젝트의 여러 소통 방식을 디스코urs로 전환하는 작업을 진행 중이며, 이러한 변화에 기대가 큽니다.
설정을 하는 과정에서 마주친 문제 중 하나는 디스코urs로 전송된 이메일에서 -----와 같은 줄 이후의 내용이 자동으로 제거되는 현상입니다. 제 이해가 맞다면, 이는 이메일을 통해 작성된 게시글에 답장 전체 사슬이 함께 포함되는 것을 방지하기 위한 조치인 것 같습니다. 실제로 디스코urs에서 이메일 기반 답장이 얼마나 깔끔하게 렌더링되는지 인상적이어서, 이 질문에서 해당 선택 자체를 비판하려는 의도는 전혀 없습니다.
저희는 과거부터 스크립트로 생성된 알림 이메일에서 구식이나 신식 기술을 사용하든 가독성을 높이기 위해 이러한 구분선을 자주 사용해 왔습니다. 현재는 이를 제거하고 대신 "수직 여백을 더 많이 사용해 보자"는 식의 기법으로 대체하는 작업을 진행 중이지만, 이 노력을 더 깊이 들어가기 전에 디스코urs로 전송되는 이메일에서 이러한 구분선을 만드는 다른 권장 모범 사례가 있는지, 아니면 현재의 필터를 우회하거나 이스케이프하는 방법을 찾지 못한 것이 아닌지 확인하고 싶었습니다. (지금까지의 최선은 하이픈/ASCII 마이너스 대신 n개의 대시 줄을 사용하는 것이었지만, 단순성을 위해 비-ASCII 문자를 사용하긴 꺼려집니다.)
또한 저희 중 일부는 코드 블록 등을 구분하기 위해 이메일에서 작은 --- 구분선을 습관적으로 사용하기도 합니다. 그래서 스크립트로 생성된 메시지들을 모두 전환하더라도, 디스코urs 토픽이 수신함으로 반영되는 경우 답장 옵션에 의존하는 사용자들에게 이 문제가 영향을 줄까 봐 걱정됩니다(아마도 넘어야 할 학습 곡선일까요?).
아하… 이 스레드에 오신 다른 분들에게 도움이 될 수 있는 것을 방금 직접 발견했습니다: 구분선 역할을 하는 줄에 구분 기호/문자 기호가 아닌 ASCII 심볼을 섞어 넣으면 Discourse의 필터링을 통과할 수 있습니다. 따라서 다음과 같은 줄:
Header
--------------------------------
을 다음과 같이 변경하면:
--- Header ---------------------
Discourse가 이를 제거하지 않고 구분선 형태의 일부 기능을 유지할 수 있는 방법 중 하나가 됩니다. 물론, 이메일에서 작은 ---- 구분선에 의존해 내용을 구분하는 데 익숙한 사용자에게는 여전히 도움이 되지 않으므로, 이 문제에 대해 다른 분들이 권장하는 모범 사례가 있는지 여전히 궁금합니다.
혼자 계속 말하고 있는 것처럼 들릴 위험을 감수하고, 오늘 실제로 마주친 구체적인 동기가 있는 예시를 하나 들어보겠습니다.
스크립트를 사용하여 이벤트 발생 시 사람들에게 알림을 보내는 경우 중 하나는, GitHub 저장소에 새로운 PR이 병합될 때 개발자에게 이메일을 보내는 것입니다. 이제 우리는 이 스크립트들을 변경하여 Discourse 사이트의 특정 카테고리로 메일을 보내도록 했습니다. 하지만 GitHub는 PR을 설명할 때 마크다운을 사용하기 때문에, PR 설명에 다음과 같은 섹션 헤더가 자주 포함됩니다:
Details of this PR
------------------
이것은 GitHub에서 섹션 헤더로 렌더링됩니다. 그러나 Discourse로 메일로 전송되면, 이 대시(-) 줄 때문에 메시지의 나머지 부분이 잘려 나가는 문제가 발생합니다.
물론 모든 개발자에게 잘리지 않는 다른 스타일의 헤더(예: ## Details of this PR)를 사용하도록 교육할 수는 있습니다. 하지만 병합 메시지를 처리하는 스크립트를 수정하여 이러한 패턴을 보호하거나 이스케이프 처리함으로써 Discourse까지 원본 그대로 유지할 수 있는 방법이 있다면, 그것이 훨씬 매력적인 해결책이 될 것입니다.