“리치 텍스트 에디터” 모드에서 편집기에 붙여넣을 때, 클립보드 데이터의 white-space CSS 속성이 무시됩니다. 이로 인해 붙여넣은 콘텐츠의 공백이 항상 축소됩니다. 원본 콘텐츠에 white-space 속성이 pre 값으로 설정되어 있는 경우, 붙여넣은 콘텐츠가 읽기 어렵게 되며, 원본 콘텐츠의 공백이 기술적 의미를 가지는 경우 오류가 발생합니다.
재현 단계:
다음 내용을 가진 HTML 파일을 생성합니다:
<html>
<body>
<span style="white-space: pre">foo
bar
</span>
</body>
</html>
웹 브라우저에서 파일을 엽니다.
페이지 콘텐츠의 공백이 축소되지 않음을 확인하세요:
foo
bar
웹 페이지의 내용을 복사합니다.
게시글 편집기를 엽니다.
편집기를 “리치 텍스트 에디터” 모드로 설정합니다.
복사한 내용을 붙여넣습니다.
복사된 콘텐츠와 동일한 형식이 아니라, 붙여넣은 콘텐츠의 공백이 축소되었습니다:
foo bar
추가 정보:
ProseMirror가 white-space: pre를 지원함을 확인했습니다:
편집기를 “Markdown 에디터” 모드로 사용할 때 이 오류는 발생하지 않습니다.
일반적인 에디터 모드 대신 코드 블록에 콘텐츠를 붙여넣을 경우에도 이 오류는 발생하지 않습니다. white-space: pre와 같은 것을 사용하는 콘텐츠를 코드 블록에 배치하는 것이 가장 적절할 수 있는 경우가 많긴 합니다. 그러나 사용자가 편집기에 콘텐츠를 추가한 후, 콘텐츠를 선택하고 편집기 툴바를 사용하여 서식을 적용하는 방식으로 사후에 서식을 적용하는 것이 상당히 흔합니다(콘텐츠를 추가하기 전에 코드 블록을 트리거하는 대안적 접근 방식과 반대되는 경우).
Arduino Cloud Editor의 “Copy Console Output” 버튼을 클릭한 후 클립보드에 어떤 데이터가 있는지 확인하기 위해 “Clipboard Inspector” 도구를 사용해 보았더니, 다음과 같은 “text/plain” 형식의 데이터가 포함되어 있는 것을 확인할 수 있었습니다:
수정해 주셔서 정말 감사합니다, @renato. 여기에 업데이트를 게시해 주신 시간까지 감사드립니다!
최근 버그 수정으로 인해 리치 텍스트 편집기의 기능이 비기술적 사용자에게 접근성을 높이는 수준까지 향상되었습니다. 이들은 마크다운에 이미 익숙하지 않으며, 마크다운을 배우려는 동기도 없습니다.
아직도 결과가 기대와 다르게 나타나는 몇 가지 조건이 있지만, 이는 Discourse 코드베이스를 통해 합리적으로 완화할 수 있는 사항들이 아닙니다:
우발적인 마크업 문법으로 인한 손상
내용이 우연히 마크업과 유사한 경우 게시물이 손상될 수 있습니다. 이는 리치 텍스트 편집기에서 마크업을 지원하도록 의도적으로 결정했기 때문입니다.
마크다운 편집기를 사용하려는 사용자는 마크다운 편집기를 사용하고, 리치 텍스트 편집기는 마크업 사용에 관심이 없는 사용자만을 위해 제공되는 우리의 사용 사례에서, 이는 매우 불행한 결정입니다. 비기술적 사용자가 마크다운 편집기를 사용할 때 우발적인 마크업으로 인한 게시물 손상은 우리가 직면한 가장 심각한 문제 중 하나였으며, 리치 텍스트 편집기가 이를 해결해 줄 것으로 큰 희망을 걸었습니다. 그러나 포럼이 리치 텍스트 편집기만 제공하는 사용 사례에서는, 이 설계는 마크다운에 능숙한 사용자가 여전히 효율적으로 게시물을 작성할 수 있게 해주므로 완벽하게 타당합니다.
클립보드 내용의 부적절한 마크업으로 인한 잘못된 서식
특정 애플리케이션에서 복사할 때 클립보드에 추가되는 “text/html” 타입의 내용에 부적절한 HTML 마크업이 포함되어 있어, 코드 블록 외부의 리치 텍스트 편집기에 붙여넣을 때 서식이 잘못 적용되는 사례가 있습니다.
이것은 물론 해당 애플리케이션의 버그이며, Discourse는 마크업이 지시한 대로 내용을 서식화함으로써 100% 올바르게 작동하고 있습니다.
물론입니다. 이 정보가 도움이 되길 바랍니다. 이전 제 발언을 다시 한 번 강조하고 싶습니다:
다만, 제 생각이 틀렸을 수도 있습니다 .
다음 C++ 코드를 복사하세요:
#include <iostream>
int main() {
std::cout << __FILE__;
}
게시물 작성기를 열립니다.
작성기를 “리치 텍스트 에디터” 모드로 설정합니다.
복사한 내용을 작성기에 붙여넣습니다.
내용이 손상됩니다:
#include
int main() {
std::cout << FILE;
}
(<iostream>이 지원되지 않는 HTML 태그와 유사하여 제거되었고, __FILE__가 굵은 글씨 마크업으로 처리되었음을 유의하세요)
이것은 비프로즈(non-prose) 내용을 붙여넣기 전에 코드 블록을 트리거하면 피할 수 있으므로 사용자 오류로 볼 수도 있습니다. 그러나 붙여넣은 내용에 사후적으로 코드 블록 서식을 적용하는 대안 워크플로우도 동등하게 유효해야 한다고 기대할 수 있습니다(Markdown 에디터 사용 시와 같이).
void setup() {
Serial.begin(9600);
while (!Serial) {} // Wait for serial port to be opened.
delay(500); // Some boards require a delay after serial port initialization.
Serial.println("foo");
Serial.println("bar");
}
void loop() {}
Arduino IDE 메뉴에서 Tools > Serial Monitor를 선택하여 Serial Monitor 뷰를 엽니다(이미 열려 있지 않은 경우).
Arduino IDE 2.x Serial Monitor가 복사된 “text/html” 유형 내용의 각 줄을 <pre> 태그로 잘못 감싸기 때문에, Discourse 리치 텍스트 에디터가 붙여넣은 내용의 각 줄을 별도의 코드 블록으로 렌더링하는 것은 정확하고 예상된 동작입니다.
위에서 설명한 다른 문제와 마찬가지로, 내용을 붙여넣기 전에 선제적으로 코드 블록 서식을 트리거하면 예상치 못한 서식 문제를 피할 수 있습니다.
붙여넣은 일반 텍스트를 마크다운으로 파싱하는 것은 예상되는 동작이며, 그렇게 하지 않으면 사용자 경험이 더 나빠진다고 생각합니다(제 의견). 하지만 실질적인 제안은 환영합니다. 마크다운으로 파싱하지 않고 붙여넣는 기능을 위해 SHIFT 수정키를 지원하는 것이 도움이 될까요?
이것은 변경할 수 있으며, 하나의 가능성은 제거하는 대신 \<iostream\>로 이스케이프 처리하는 것입니다.
“리치 텍스트 에디터” 모드에서 편집기에 붙여넣을 때, 클립보드 데이터의 
.
내용이 손상됩니다: