새로운 스택 편집기를위한 옵트 인 알파 테스트

Question

요약 : Markdown 및 서식있는 텍스트 입력 옵션을 모두 제공하는 새로운 오픈 소스 스택 편집기를 테스트하고 있습니다. 테스트하고 피드백을 제공하는 데 관심이있는 경우 환경 설정 페이지 를 방문 하여 스택 편집기를 활성화 하여 선택할 수 있습니다 . 언제든지 선택 해제 할 수 있지만 이전 편집기로 되 돌리는 데 최대 10 분이 소요됩니다. 새 편집기는 알파 테스트 중에 MSE 또는 MSO에서 답변 을 작성하거나 편집 할 때만 활성화됩니다 .

---

약 6 개월 전, 우리 제품 팀과 커뮤니티 팀은 여름 에 Stack Overflow for Teams (또는 Teams)에서 시작된 Stacks 서식있는 텍스트 게시물 편집기를 공개 사이트에 가져올 수 있는지 알아보기 시작했습니다 . 우리는 그 시간을 내부적으로 필요에 대해 논의하고 사용하기 위해 변경하거나 포함해야 할 사항을 이해하기 위해 새로운 편집자 인 중재자 및 Charcoal 그룹 구성원에 대해 가장 참여도가 높은 사용자와 이야기했습니다. 새 편집기는 이전 편집기에서 쉽게 전환 할 수 있습니다.

이 과정을 통해 우리는 개선을위한 아이디어, 제거해야 할 버그, 해결해야 할 UX 혼란과 함께 수십 개의 답변을 받았습니다. 우리는이 두 그룹이 언급 한 많은 문제를 해결했으며 MSE 및 MSO에 대한 옵트 인 알파 테스트를 통해 더 큰 커뮤니티에이를 가져올 준비가되었습니다. Markdown에 익숙한 사람과 서식있는 텍스트에 더 익숙한 사람이 성공적으로 사용할 수있는 도구로 만들기 위해 개선의 여지가 있는지 확인하기 위해 건설적인 피드백을 요청하고 있습니다.

두 가지보기의 모양은 다음과 같습니다. 클릭하면 더 큰 이미지를 볼 수 있습니다.

시험

이 알파 테스트의 목표는이 새 편집기를 얼마나 잘받을 수 있는지에 대한 초기 이해를 얻고 현재 편집기를 좋아하거나 Markdown에서 작업하는 것을 선호하는 사용자의 워크 플로를 중단시킬 우려를 발견하는 것입니다. 또한 Markdown에 익숙하지 않은 사용자도 비 기술 사이트의 많은 사용자를 구성하므로 고려하고 싶습니다. 이것은 우리가 편집자를 완전히 테스트하고 개선하기를 희망하는 프로세스의 첫 번째 공개 단계로, 네트워크 전체에 출시 될 때 사람들이 사용하기 쉽고 현재 편집자보다 크게 개선 될 수 있습니다.

우리는 리치 텍스트 입력이 제대로 작동하기 어렵다는 것을 이해하고이를 네트워크 전체에 적용하기 전에 올바른 솔루션을 찾는 데 몇 달이 걸릴 수 있다는 것을 알고 있으며, 이는 극복 할 수없는 문제가있을 수 있다는 이해와 함께 제공됩니다. 우리는 여러분과 함께이 프로세스를 진행하는 것이 최소한 Teams의 새로운 편집자 경험을 개선하는 데 도움이되며 모두가 사용할 수있는 훌륭한 새 편집자가 될 수 있다고 생각합니다.

이것은 다음과 같은 다중 파트 테스트의 일부입니다.

• 참여도가 높은 사용자 (예 : 중재자)의 피드백이 포함 된 Teams의 초기 릴리스 (2020 년 여름 완료). 이것의 목표는 피드백을 받고 우리의 퍼블릭 플랫폼 커뮤니티에서 작동하도록 에디터를 얼마나 변경해야하는지에 대한 좋은 아이디어를 얻는 것이 었습니다. 이를 통해 공개 사이트에 영향을주지 않고 소규모 그룹으로 많은 기능 (전부는 아니지만)을 테스트 할 수있었습니다.
• 옵트 인 알파 테스트를 통해 MSE 및 MSO에서 테스트합니다. 여기서 목표는 주로 커뮤니티의 활동적인 구성원 인 사용자가 새 편집자를 공개적으로 채택하는 데 도움이되는 솔루션을 더욱 구체화하고 식별하는 것입니다.
• 다양한 경험 수준의 사용자와 사용성 테스트 세션. 여기서의 목표는 참여도가 높은 사용자에게 응답 한 후 생성하는 기능과 UX가 여전히 다른 사용자에게 투명하도록하는 것입니다. 다양한 경험 수준의 사용자가 편집기와 상호 작용하여 필요한 곳에 충분한 지침이있는 직관적 인 사용자 경험을 식별하고 추가로 개선하는 방법을 살펴 봅니다.

타임 라인에 관해서는이 작업을 완료하는 데 시간이 걸릴 것으로 예상됩니다. 알파 테스트의 이점 중 하나는 사람들이 원하는대로 활성화 및 비활성화 할 수 있다는 것입니다. 2021 년 1 분기의 나머지 기간 동안 우리의 계획은 여러분이 원하는 경우 모두가 더 장기적으로 시험해 볼 수 있도록 테스트를 계속 실행하는 것입니다. 주요 버그를 수정하는 동안,이 테스트에서 얻은 피드백과 2021 년 2 분기 사용성 세션의 피드백을 조사하기 전까지는 새로운 기능이나 조정의 우선 순위를 정하지 않을 것입니다. 자세한 내용은 다음에서 확인하세요. 아래의 피드백 제공 섹션.

이러한 테스트가 잘 진행되고 현재 시스템보다 포스트 생성 및 편집을 더 쉽게 만드는 솔루션을 찾은 경우 MSE 및 MSO로 다시 시작한 다음 표준 편집 도구를 사용하여 사이트를 예약하는 점진적 롤아웃 단계로 이동합니다. 마지막에 전문 편집기 애드온을 사용하여 시작시 도구가 올바르게 작동하는지 확인할 수 있습니다.

---

사이트에 서식있는 텍스트 편집기를 제공하기 위해 노력하는 이유는 무엇입니까?

수년 동안 서식있는 텍스트 입력 옵션에 대한 요청이 있었지만 ( 이는 2009 년으로 거슬러 올라갑니다 ) 사용자의 지원은 많지 않았습니다. 실제로 많은 요청이 다른 사용자로부터 강한 불일치가 발생합니다. . Markdown은 훌륭한 도구이며 많은 사용자들이 그것에 익숙해 졌거나 익숙해졌습니다. 저는 Markdown을 서식있는 텍스트 공간에서 정기적으로 사용하려고한다는 것을 인정합니다. 즉, 이러한 요청의 대부분은 마크 다운을 서식있는 텍스트 로 대체하기위한 것이 었으며 이는 우리가 원하는 것이 아닙니다.

프로그래머가 주로 사용하는 플랫폼 인 Markdown은 일반적으로 많은 사람들에게 친숙한 형식이며 특히 CommonMark 표준을 따르기 때문에 매우 편안하게 사용할 수 있습니다. Markdown을 모르는 사람들을 위해 우리는 그들이 배우기를 기대했고 그들에게 약간의 도움을 주었지만, 많은 경우 게시물의 형식이 잘못되어 개선을 위해 커뮤니티의 참여가 필요합니다. 영어 학습자에 대한 나의 편집의 대부분은 순전히 포스트 형식을 개선하기위한 것입니다.

또한 에디터는 처음부터 그 당시에는 거의 개선되지 않았기 때문에 대대적 인 업그레이드가 필요하며 앞으로도 Stacks를 사용하는 재 설계된 에디터가 앞으로 더 쉽게 유지되고 개선 될 것이라고 생각합니다.

팀에는 서식있는 텍스트 옵션이 필요했습니다.

내부 지식 공유에 사용하는 회사 및 조직의 요구 사항을 충족하기 위해 Teams 제품을 개선하기 위해 노력하는 훌륭한 팀이 있습니다. 이러한 사용자의 빈번한 고통 중 하나는 서식있는 텍스트 편집기가 없다는 것입니다. 여기 Teams 개발자 중 한 명인 Ham의 진술이 있습니다.

Teams 고객을위한 Stack Overflow의 피드백에 대한 응답으로 새로운 Stacks Editor를 구축하기 시작했습니다. Markdown은 Stack Exchange뿐 아니라 웹 전체에서 콘텐츠를 작성하는 데 널리 퍼지고 성공적인 형식이되었지만 일부 Teams 고객은 Markdown에서 콘텐츠를 작성하는 것이 불편하다고 말했습니다. 그들은 구문을 몰랐고 원하는 방식으로 쓰기를 시작하기 전에 학습 곡선에 직면했습니다. 질문과 답변을 작성하는 것은 다른 곳에서 익숙한 것만 큼 쉽지 않았습니다. 우리에게 가능한 한 쉽게 기여하는 것이 중요합니다. 질문과 답변을 작성하는 것은 자연스럽고 마찰이 없어야합니다.

이것은 의미가 있습니다. Google 문서 또는 Word와 같은 서식있는 텍스트 편집기에서 복사하여 붙여 넣는 것은 기존 문서에서 팀으로 정보를 전송할 수있는 회사 내에서 훨씬 더 일반적이지만, 대부분의 공개 사이트 콘텐츠는 처음부터 만들어집니다. 즉, 따옴표 형태의 콘텐츠를 게시물에 복사하는 것은 전례가없는 일입니다. 여기에는 서식있는 텍스트 감지 기능이 도움이되어 Markdown을 수동으로 추가 할 필요가 없습니다.

새 편집기 개발의 주요 원동력은 기존 사용자를 위해 Teams의 경험을 개선하고 추가 사용자를 끌어들이는 기능 세트를 제공하는 것이 었습니다. 즉, Teams를 사용하는 많은 사람들이 개발자 중심 그룹이므로 Markdown에 익숙한 경우가 많으므로 두 옵션을 모두 사용할 수 있는지 확인하고 싶었습니다. 햄에서 더 :

새로운 스택 편집기는 두 세계 모두에서 최고가 되려고합니다. Markdown 작성에 만족하고 이전 편집기가 도움을 준 방식이 마음에 든다면 새 편집기는 매우 친숙 할 것입니다. Markdown을 작성하고, 익숙한 키보드 단축키를 사용하고, 이미지를 업로드하는 등의 작업을 할 수 있습니다. Markdown이 당신의 강점이 아니라면 Stacks Editor를 사용하면 좀 더 WYSIWYG 방식으로 글을 쓸 수있는 새로운 서식있는 텍스트 모드로 전환 할 수 있습니다.

우리는 여전히 Markdown이 갈 길이라고 생각하지만 기술이 덜한 사용자 및 / 또는 WYSIWYG 스타일 편집에 더 익숙 할 수있는 네트워크 사이트를위한 서식있는 텍스트 편집기의 이점도 있습니다. 새로운 Stacks Editor를 사용하면 Markdown은 계속해서 콘텐츠의 주요 형식이되고 작성하는 모든 내용은 하루가 끝나면 Markdown으로 변환되어 저장됩니다.

따라서 새 편집기를 만드는 데 초점을 맞춘 것은 서식있는 텍스트 옵션을 추가하는 것이었지만 Markdown을 좋아하고 이미 사용 방법을 알고 있고 비교적 배우기 쉬운 사람들에게는 훌륭한 경험이라고 생각하기 때문에 여전히 Markdown 초점을 유지하는 것이 었습니다. 또한 게시물에 복사하여 붙여 넣거나 Markdown을 모르는 사람들을 위해 경험을 단순화하거나 개선하고자합니다.

단순한 서식있는 텍스트가 아니라 향후 개발 작업을 단순화하고 있습니다.

현재 편집기는 2008 년부터 사용되어 왔으며 그 과정에서 변경했지만 거의 변경되지 않았으며 이제 새로운 기능을 구축하기가 어렵습니다. 또한 공용 네트워크에서 Teams 편집기를 채택하고 개선하여 페이지 요청, 답변 및 편집에 대한 향후 작업을 단순화하고 Teams와 네트워크간에 유사한 기능을 유지하고 있습니다. Ham의 마지막 인용문 :

우리의 오래된 편집기는 수년 동안 우리를 잘 지원해 왔지만 여러 문제 (작업하기 어려운 리버스 엔지니어링 코드, 브라우저 간 문제를 처리하기위한 부적절한 API, 베어 본 콘텐츠 편집 가능 지원)로 인해 주요 업그레이드의 기반으로 사용할 수 없습니다. 또한 편집자를 현대적 기반 (예 : prosemirror 위에서 수행 한 것처럼)에 기반하여 많은 이점 이 있습니다. 이는 많은 "콘텐츠 편집 가능"문제를 처리하고 작업을보다 안전하고 크로스 브라우저에서 유지할 수 있습니다. 호환됩니다.

너무 오랫동안 주변에 있었기 때문에 꽤 찌꺼기가 쌓였 고 우리가 원하는 방식으로 유지하고 발전시키기가 어려워졌습니다. 지난 몇 년 동안 우리는 편집자가 너무 힘들다는 것을 알아 내기 위해 몇 번만 편집자를 수정했습니다. Teams 용 새 편집기를 구축하기 시작했을 때 우리는 이것이 궁극적으로 네트워크 전체의 모든 사용자에게 혜택을 줄 새 편집자 를 개발할 수있는 좋은 기회가 될 것임을 알았습니다 .

또한 모든 사람이 사용하고 기여할 수 있도록 편집기를 엽니 다. Stacks와 마찬가지로 새 편집기는 오픈 소스이므로 빌드 방식에 관심이 있거나 개선에 기여하고 싶다면 Stacks-Editor repo 에서 찾을 수 있습니다 .

편집자를 만드는 것은 어렵다-특히 리치 텍스트를 다룰 때

내가 참여한 포럼의 BBCode, MediaWikis의 Wikitext, Stack Exchange의 Markdown, 다양한 리치 텍스트 또는 다양한 편집자 등 다양한 편집자들의 특이한 점을 수년에 걸쳐 배웠습니다. 내가 사용한 플랫폼 (예 : Jira, FreshDesk)… 그래서 새로운 스타일에 적응하는 것이 편하지만 일부 편집자들은 나를 좌절시키고 혼란스럽게하고 더 이상 사용하고 싶지 않게 만드는 가정을합니다. 우리는 이러한 좌절을 피하고 싶습니다!

표와 스포일러에 대한 특수 서식을 추가하여 마크 다운에 초점을 맞추고 있기 때문에 서식있는 텍스트 편집기가 수행해야하는 작업을 제한 할 수 있습니다. 사용 가능한 서식 옵션 (예 : 다채로운 텍스트 또는 밑줄)을 늘리지 않습니다. 이는 리치 텍스트 구현과 리치 텍스트와 마크 다운 간의 변환을 간단하고 이해하기 쉬우 며 최대한 실망스럽지 않게 유지하기 위해 노력하고있는 한 가지 방법입니다.

주요 변경 사항

선택적인 서식있는 텍스트 항목 외에이 테스트에서 볼 수있는 크고 작은 변경 사항이 많이 있습니다. 다음은 서식있는 텍스트 입력이 작동하는 방식에 대한 간략한 개요를 포함하여 가장 큰 몇 가지 항목입니다. 아래에 쓰여진 내용 중 상당수는 Ben Kelly가 작성했습니다. Ben Kelly는이 편집기를 사용하기 위해 Ham과 많은 작업을 수행했으며 기능에 대해 매우 잘 알고 있습니다. 덕분에 그에게 큰 감사를드립니다!

서식있는 텍스트 모드

이 편집 모드는 많은 사용자가 사용하는 기존의 워드 프로세싱 소프트웨어와 거의 유사하도록 설계되었습니다. 그러나 몇 가지 추가 기능이 추가되었습니다.

• 블록 레벨 구문을 위한 마크 다운 스타일 "입력 규칙"
  • #, ## 등을 입력하면 헤더가 생성됩니다. 입력> 따옴표를 만듭니다. * 목록을 생성하는 등
  • 향후 릴리스를 위해 조사 할 항목 목록에 인라인 입력 규칙 (굵게, 기울임 꼴, 인라인 코드 등)이 있습니다.
• 링크 및 이미지 편집 도구를 사용하면 링크에 대한 링크 URL을 편집하고 이미지에 대한 이미지 설명 및 제목을 추가 할 수 있습니다.
• 지능적인 복사 / 붙여 넣기 지원-예를 들어 Google 문서 도구 또는 선택한 편집기의 코드에서 외부 콘텐츠를 붙여 넣으면 형식이 Markdown에있는 경우 기존 형식의 대부분이 유지됩니다.

궁극적으로 리치 텍스트 편집기는 Markdown으로 다시 변환되며 몇 가지주의 사항과 함께 Markdown에서 할 수있는 모든 작업을 지원해야합니다.

• 특히 매우 복잡한 콘텐츠의 경우 외부 소스의 서식있는 텍스트를 붙여 넣는 것은 완벽하지 않습니다.
• 서식있는 텍스트 모드에서 지원할 수있는 것은 지원 마크 다운 구현에 의해 제한되므로 HTML을 지원하더라도 테이블의 병합 된 셀이나 위 / 아래 첨자와 같은 것은 지원되지 않습니다 (다음 글 머리 기호 참조).
  • 이것은 단점 이라기보다는 기능에 가깝습니다. 우리는 Markdown <3이며 가까운 미래를 위해 일류를 지원하기 위해 최선을 다하고 있습니다.
• HTML 지원은 어렵습니다. 마크 다운 모드로 작성된 HTML이 서식있는 텍스트 모드에서 편집 가능할 것이라고 약속하지 않습니다.
  • 가능한 경우 동등한 commonmark 구문을 사용하는 것이 좋습니다. 사용자가 더 이상 HTML을 입력 할 필요가 없도록 지원되는 Markdown 구문을 확장하려고합니다.
  • HTML이 왜 어려운지 묻지 마십시오 . 자체 블로그 게시물이 될 수있는 긴 이야기입니다.

Markdown-서식있는 텍스트 전환기

서식있는 텍스트와 마크 다운 모드 간 이동을 허용하기 위해 스위치를 추가했습니다. 점이 오른쪽 (녹색 배경)에 있으면 마크 다운 모드에있는 것입니다. 왼쪽 (회색 배경)은 서식있는 텍스트 모드입니다. 모든 사용자의 현재 기본값은 Markdown이지만 편집기를 사용한 후 시스템은 마지막으로 사용한 옵션을 기본값으로 기억합니다. 따라서 Markdown보기에서 게시물을 제출하거나 편집하면 다음에 편집기를 열 때이를 확인할 수 있습니다. 서식있는 텍스트로 그렇게하면 다음에 사용할 때 볼 수 있습니다. 사용자에 대한 기본 구성은 사이트별로 변경할 수 있으므로 사이트에서 서식있는 텍스트가 기본값으로 더 적합하다고 판단되면이를 허용 할 수 있습니다.

미리보기가 서식있는 텍스트보기로 축소됩니다.

수년 동안 우리는 미리보기를 최적화하여 화면의 많은 공간을 차지하지 않도록 할 수 있는지에 대해 많은 질문을 받았습니다. 긴 게시물을 작성한 적이 있다면 미리보기 끝에서 편집 창으로 돌아 가기 위해 스크롤을 많이하는 느낌에 익숙 할 것입니다. 새 편집기를 사용하면 Markdown 토글을 사용하여 Markdown과 서식있는 텍스트 모드 사이를 전환하여 미리보기를 볼 수 있으며 서식있는 텍스트 미리보기는 편집기의 일부이므로 편집 창을 찾을 필요없이 미리보기에서 바로 편집 할 수 있습니다. 다시. 이것은 짧은 포스트를 스크롤하는 것이 많은 작업을 의미 할 수있는 작은 화면으로 인해 모바일 사용자에게도 훨씬 더 편리합니다.

디자인 시스템의 수석 제품 디자이너 인 Aaron이 편집 가능한 미리보기의 가치를 설명합니다.

우리는 이것이 레이아웃 문제 이상이라고 생각합니다. 이 미리보기를 나란히 놓거나 GitHub처럼 전환 할 수 있지만, 미리보기를 갖는 것은 우리가 넘어갈 수있는 것입니다. 작은 주석 : 저는 2016 년에 GitHub의 편집기에서 일했습니다! 전체 화면 미리보기를 시작하는 버튼이있는 것과 같은 대안을 탐색 할 수 있지만, 미리보기 환경에서 직접 작성할 수있을 때는 낭비라고 생각합니다.

웹은 Markdown 구문 및 개별 미리보기가 필요한 시점을지나 성숙해졌습니다. 2021 년에 텍스트 편집이 읽기 전용 미리보기 상태를 제공해야하는 이유는 무엇입니까? 글을 쓰고, 미리보고, 실수를 발견하고, 편집기로 돌아가는 것이 단순히 텍스트를 편집 할 수있는 것보다 진정으로 더 낫습니까? 워드 프로세서에서이 상호 작용 모델을 받아들이시겠습니까? Notion에서? Google 문서에서? Medium에서?

우리는 이것이 이러한 이유들과 다른 많은 이유들에 대해 긍정적 인 변화라고 생각하지만 이것이 현재 형식에서 크게 벗어났다는 것을 이해합니다. 시간을내어이 새로운 워크 플로가 어떻게 느껴지는 지 확인하고 귀하의 생각과이를 개선 할 수있는 방법을 알려주십시오. 이전의 많은 요청이 많은 사람들이 가지고있는 더 넓은 화면에 맞추기 위해 나란히 미리보기를 요청한 것임을 알고 있습니다. 특히 다른 많은 Markdown 편집자와 일치하기 때문입니다. 안타깝게도 작은 화면에서는 복잡 할 수 있으므로 다른 배치가 필요하며 GitHub의 두 탭 형식과 같이 입력 양식과 별도로 미리보기를 갖는 것이 일반적입니다.

여기에 몇 가지 알려진 문제가 있습니다.

• 모드 간 전환은 대략적인 스크롤 위치를 유지하지만 커서가 어디에 있는지 기억하지 못합니다. 전환 할 때마다 커서는 현재 위치에 머 무르지 않고 게시물 상단으로 다시 이동합니다.
• 모드를 전환 할 때 기록이 없으므로보기간에 전환하면 다른보기에서 변경 사항을 실행 취소 / 다시 실행하는 기능을 잃게됩니다.
• 서식있는 텍스트 미리보기는 마크 다운을 해석하므로 잘못된 마크 다운 (MD)은 서식있는 텍스트 편집기에서 이스케이프 처리 될 수 있습니다. MD보기로 돌아 가면 이러한 오류를 수정할 수 있습니다.

마크 다운 모드에서 구문 강조

Markdown 경험은 이제 창에서 텍스트를 변경하여 사용하는 Markdown에 응답하기 때문에 약간 덜 단조롭다는 것을 알 수 있습니다. 제목은 더 커지고 굵은 텍스트는 기울임 꼴처럼 굵게 표시되며 링크는 파란색으로 표시됩니다. 코드는 회색입니다. 필자가 만들었을 수있는 많은 Markdown 오류를 식별하여 미리보기를 볼 필요조차 없게 만드는 것이 게시물 초안 작성에 정말 도움이된다는 것을 발견했습니다. 이것은 현재 CommonMark를 준수하지 않지만 개선을 위해 노력하고 있습니다.

서식 버튼 변경

일부 단추를 제거하고 서식을 지정할 수있는 단추에 몇 가지 새 단추를 추가했습니다. 이제 서식 지정 막대의 모양은 다음과 같습니다.

제거됨 :

• 실행 취소 / 다시 실행 -이러한 기능은 여전히 ​​표준 키 조합으로 작동하지만 버튼 자체를 제거했습니다. 실행 취소 / 다시 실행 기록 지원을 전반적으로 훨씬 더 안정적으로 개선했습니다.
• 스택 스 니펫 (임시)-초기 알파 테스트에 스 니펫을 빌드 할 수 없으므로 게시물에 스 니펫을 추가해야하는 경우 알파를 비활성화해야합니다.

업데이트 / 신규 :

• 표 -이 버튼은 기본 3 행 2 열 표를 만들고 행과 열을 추가 / 제거 할 수있는 서식있는 텍스트 모드에서 특수 메뉴 옵션을 갖습니다.
  
  
• 헤더 -이 버튼은 다시 디자인되어 첫 번째 위치로 이동되었습니다.
• 인라인 코드 / 코드 블록 / 스택 스 니펫 버튼 -초기 테스트에서 얻은 피드백 중 하나는 서식있는 텍스트의 경우 인라인 코드와 코드 블록을 구분해야한다는 것이었지만 Teams에서는 현재 사용하는 코드 블록에 동일한 아이콘을 재사용했습니다. 스택 스 니펫-세 가지 옵션을 모두 허용하기 위해 새 아이콘을 만들었습니다. 알파에는 스 니펫이 비활성화되어 있지만 새로운 트리오 버튼 (왼쪽에서 오른쪽으로-인라인 코드, 코드 블록, 스 니펫)을 볼 수 있습니다.
  
  

서식 지정 버튼에 키보드 단축키를 추가 할 계획이지만이 초기 알파 테스트에는 포함되지 않습니다.

Markdown 모드는 게시물을 미세 조정하는 데 유용합니다.

마크 다운 모드는 이미 그렇듯이 게시물을 더 완벽하게 제어 할 수 있습니다. 게시물을 작성하거나 편집 할 때 MD를 고수하고 싶은 몇 가지 장소는 다음과 같습니다.

• 구문 강조를 위해 코드 블록에 언어 추가 -이 기능을 서식있는 텍스트에 추가하려고하지만 지금은 MD가 필요합니다. 시스템은 일반적으로 태그를 기반으로 언어를 자동 감지하지만 특정 언어를 호출해야하는 경우 Markdown 모드를 사용해야합니다.
• HTML이 필요한 마크 업 -게시물에서 일부 HTML을 여전히 지원하지만 서식있는 텍스트 모드에서는이를 생성하지 않습니다. 따라서 아래 첨자 또는 위 첨자와 같은 서식을 지정하기 위해 게시물에 HTML을 포함해야하는 경우 다음을 위해 마크 다운 모드를 입력해야합니다. 이.
• 스포일러 -HTML과 같이 지원되지만 버튼이 없으므로 마크 다운 모드를 사용하여 추가해야합니다.
• 복잡한 목록 만들기 -서식있는 텍스트 모드에서 가능하지만 특히 들여 쓰기 된 코드 블록이있는 목록과 같은 특수한 경우에는 Markdown을 사용하는 것만 큼 직관적이지 않습니다.
• 이미지 미세 조정 -소스 또는 전체 크기 이미지의 크기를 조정하거나 링크를 추가하려면 마크 다운 모드가 필요합니다.

인라인 텍스트 및 이미지 링크가 표준입니다.

이미지 및 링크 도구는 이제 참고 문헌 형식이 아닌 인라인으로 이미지 및 링크를 추가합니다. 후자는 여전히 작동하지만 수동으로 만들어야합니다. 현재 이미지에는 이미지와 링크 형식이 없지만 향후 릴리스에서 추가하기 위해 노력하고 있습니다.

참여 방법

알파 테스트에 옵트 인하 려면 기본 설정 페이지를 방문하여 스택 편집기 옵트 인 옵션을 활성화하여 옵트 인하십시오. 처음에 새 편집기는 답변에서만 사용할 수 있습니다. 질문, 프로필 페이지, 태그 편집 페이지 또는 사이트 주변의 기타 편집 양식에서는 볼 수 없습니다. 옵트 인은 전 세계적으로 이루어 지므로 MSE를 옵트 인하면 MSO를 사용하는 경우 새 편집기도 표시됩니다. 옵트 아웃하기로 결정한 경우 편집자가 정상으로 돌아가는 데 최대 10 분이 걸릴 수 있지만 원하는 방식으로 슬라이더를 전환하여 동일한 방식으로 할 수 있습니다.

피드백 제공

이 피드백 단계는이 과정에서 매우 중요한 부분이므로 시간을내어 에디터를 사용해 주신 모든 분들께 진심으로 감사드립니다. 버그, 사용성 문제가 발생하거나 새 편집기 사용 환경을 개선 할 기능이 생각되면 여기에 답변을 남겨주세요. 각 답변을 검토하고 답변 할 수 있습니다. 안정적으로 재현하는 단계는 버그가 발생하는 브라우저와 함께 항상 높이 평가되며, 특히 애매한 경우 또는 미묘한 사용성 문제와 관련하여 특히 그렇습니다. 또한이 프로젝트는 오픈 소스이기 때문에 진정한 기술 버그 를 위해 GitHub 저장소에 문제로 제출할 수 있습니다. 편한 경우 두 곳에서 보고서가 제출되면 링크를 거칩니다.

우리의 계획은 내부 시스템에서 GitHub 저장소로 문제를 전송하고 여기에 올라 오는 새로운 문제를 추가하여 관심있는 사람은 누구나 우리가 작업하고있는 작업과이 작업의 우선 순위를 확인할 수 있도록하는 것입니다.

편집자에 대한 전반적인 생각을 듣는 것은 좋지만, 한 게시물에 너무 많은 내용이 있으면 응답이 어려울 수 있으므로 각 답변을 비교적 간결하게 유지하십시오. 알파가 끝날 때까지 여기에 답변을 추가해야합니다. 완료되면 피드백을 제공하는 가장 좋은 방법을 알려 드리겠습니다.

감사

이 프로젝트는 그렇게 많은 사람들의 작업 없이는 불가능했을 것이며, 그들은 모두 엄청난 신용을받을 자격이 있습니다. 특히 Ben Kelly, Ham Vocke, Aaron Shekey, Des Darilek 및 Adam Lear가 노력한 모든 노력에 대해 인정하고 싶습니다. 또한 시간을내어 테스트하고 피드백을 제공 한 사람들에게 편집자는 Teams에만있었습니다. 감사합니다!

Answer 1

상태 계획

"곧은 따옴표"를 "스마트 따옴표"로 자동 변환하는 것은 코드 중심 사이트에 치명적입니다.

리치 텍스트 모드에서는 편집기 auto-converts double-quote characters into “smart quotes”, even for text entered in inline code format이지만 다행히 코드 블록에는 없습니다.

이로 인해 Stack Overflow와 같은 코드 중심 사이트에서 큰 문제 가 발생 하고 적어도 일부 다른 사이트에서 상당한 문제가 발생할 수 있습니다.

명확하게 말하면, 최소한 코드 중심 사이트의 경우, 곧은 큰 따옴표 문자를 "똑똑한 따옴표"로 자동 변환하는 모드 가 편집기에 없어야합니다 . 자동으로 그 변환 을 수행하는 모드를 가지려면 코드에 대해 자동 "스마트 따옴표"변환이 수행되어 코드 가 손상 됩니다 . 이러한 모드 를 사용 하면 원본 항목, 편집, 조정, 실제 문제 결정 등의 모든 게시물에 필요한 평균 시간과 노력 이 늘어납니다. 사용자는 종종 코드를 나중에 코드를 적용하거나 적용하지 않을 수있는 일반 텍스트로 입력합니다. 그래서 자동 "스마트 따옴표"에서 활성화 가지고, 서식 어떤 모드하는 것입니다 추가 문제가 발생할. 이러한 모드를 사용하면 도입 된 추가 문제로 인해 모든 코드 중심 사이트에 대한 전반적인 사용자 만족도가 떨어집니다.

, 기본적으로, "둥근 따옴표"로 직선 따옴표 문자 자동 변환 어떤 사람들은 "꽤 따옴표 오"생각하는 대한 기능이지만, 이는 정말 다른 사람 (어떤 사람들에 대한 근본적인 문제를 야기 정말 "스마트 따옴표는 싫어 ”). 제발, 제발 우리에게 "스마트 따옴표"를 입힐하지 않습니다.

Answer 2

부인 성명:

이 게시물의 무뚝뚝한 어조에 대해 사과하면서 시작하겠습니다. 저는 개발 측면의 기초가되는 개방성과 노력의 정신에 매우 감사 드리며, UI 개선을위한 노력과 커뮤니티 피드백을 요청하는 데 헌신 한 시간과 의지에 대해 감사드립니다. 중요하기 때문에이 피드백을 뭉툭한 가장자리로 제공합니다. 훌륭한 작업을하고 있지만주의 깊게 작업하지 않으면 심각한 피해를 입힐 가능성이 분명하고 제가 볼 수있는 대부분의 징후가 있습니다. 당신의 현재 궤도가 그 피해를 향해 가고 있음을 나타냅니다.

다음은 건설적인 비판으로 만 의도 된 것이며 =)로 읽길 바랍니다.

즉,

이 변화는 MathJax 관점에서 매우 놀라운 것입니다.

디자인 철학은 많은 사이트에 대해 많은 의미가 있지만 제안 된 몇 가지 변경 사항 (특히 라이브 미리보기 제거)은 MathJax가 사이트 경험의 공통적이거나 필수적인 부분 인 사이트에 재앙 이 될 것입니다. 다시 말씀 드리지만, 이는 전체 176 개의 네트워크 중 42 개 사이트 , 즉 네트워크 사이트의 24 % 이상 입니다.

^{(또한 의견에서 지적했듯이 MathJax와 동일한 상황에있는 몇 가지 다른 필수 사이트 별 게시물 서식 플러그인 이 있습니다. 가장 명확한 예는 chess , go , furigana 및 음악 표기법 입니다.)}

가장 걱정되는 사항은 다음과 같습니다.

이 미리보기를 나란히 놓거나 GitHub처럼 전환 할 수 있지만, 미리보기를 갖는 것은 우리가 넘어갈 수있는 것입니다.

어 .. 아니에요.

2021 년에 텍스트 편집이 읽기 전용 미리보기 상태를 제공해야하는 이유는 무엇입니까? 글을 쓰고, 미리보고, 실수를 발견하고, 편집기로 돌아가는 것이 단순히 텍스트를 편집 할 수있는 것보다 진정으로 더 낫습니까? 워드 프로세서에서이 상호 작용 모델을 받아들이겠습니까?

그래, 난 것. 이미하고 있습니다. 이것이 나의 주요 작업 방식입니다. 제 분야에서-MathJax가 보유한 SE 사이트에 표시된 많은 것과 유사하게-업계 표준 워드 프로세서는 LaTeX입니다. 별도의 편집기와 미리보기를 갖는 것은 표준 일뿐만 아니라 효율적으로 작업 할 수 있는 유일한 방법입니다.

최소한 수학 용 WYSIWYG 편집기를 구축하는 것은 주요 소프트웨어 작업입니다. 그러나 솔직히 말해서, 수십 년의 궤도를 가진 기존 솔루션 중 어느 것도 전문 표준으로 기준을 만들지 않습니다. (명확성을 위해 : 여기서 시도하는 것은 절대 말도 안되는 일입니다.) 수학을 편집 하려면 절대적 으로 코드 및 미리보기 구성이 필요 합니다. 따라서 디자인 철학이 "미리보기를 갖는 것은 우리가 넘어갈 수있는 것"이라는 것이라면, 디자인 철학은 기술 사이트의 요구 사항에 눈이 멀고 귀머거리입니다.

물론 저는이 우려에 동정합니다.

긴 게시물을 작성한 적이 있다면 미리보기 끝에서 편집 창으로 돌아 가기 위해 스크롤을 많이하는 느낌에 익숙 할 것입니다.

그리고 실제로 그것은 성가신 일이 될 수 있습니다 (지명 된 바와 같이 보편적이지는 않지만 ). 그러나 그 관점에는 MathJax가 Stack Exchange에서 작동하는 방식의 또 다른 중요한 측면이 누락되었으며, 이는 일반 텍스트 Markdown / MathJax 소스와 함께 즉시 미리보기를 렌더링 할 수있는 놀랍고도 극도의 편리함입니다 . 실제로 현재 편집기는 미리보기 새로 고침의 속도와 일관성으로 인해 표준 LaTeX 편집기보다 더 편리합니다. 변경되는 즉시 새로 고침되며 렌더링 속도 (매우 빠른)에 의해서만 제한됩니다. .

제안 된 변경 사항 (같은 창에 마크 다운 소스 및 서식있는 텍스트 미리보기, 전환 버튼이 있음)에서 수학 작성 및 편집이 눈에 띄고 상당히 어려워집니다. 솔직히 말해서 동시 미리보기를 없애는 것은 수학적 기술 사이트를 크게 만듭니다.

---

이제 코드의 나이와 유지 관리 및 추가 업그레이드의 기반으로 사용하기의 어려움에 대해 지적한 점에 감사드립니다. 편집기를위한 더 나은 코드베이스가 필요하고 배포가 끝날 ​​때 SE 네트워크 전체에 걸쳐 사용되어야한다는 것은 완전히 의미가 있습니다.

... 이것이 MathJax를 둘러싼 우려가 초기 설계 단계의 일부를 형성하는 것이 필수적인 이유 입니다. 이것은 :

MathJax를 사용하는 사이트는이 기능을 제공하는 마지막 사이트 중 하나입니다.

충분하지 않습니다. MathJax를 둘러싼 우려는 핵심 설계 결정의 일부입니다. 계획이 끝까지 기다릴 계획이라면 모든 것이 해결되고 모든 디자인 결정이 결정되고 이러한 결정이 MathJax를 사용하는 40 개 이상의 사이트에서 효과가 있기를 희망한다면 계획은 다음과 같습니다. "우리는 수학적인 기술 사이트가 결국 엉망이 되어도 상관 없습니다."

목표가 서식있는 텍스트 지향 사이트와 Teams 및 MathJax 지향 기술 사이트에 대해 단일 코드베이스 작업을하는 것이라면 처음부터 그 결합 성을 인식해야합니다. 미리보기와 관련된 디자인 결정은 지금 만들어지고 수학 사이트 (math.se, physics.se, stats.se 등-귀하의 선택)가이를 테스트 할 첫 번째 사이트 중 하나가되어야합니다.

---

하나 더:

마크 다운 모드에서 구문 강조

Markdown 경험은 이제 창에서 텍스트를 변경하여 사용하는 Markdown에 응답하기 때문에 약간 덜 단조롭다는 것을 알 수 있습니다. 제목은 더 커지고 굵은 텍스트는 기울임 꼴처럼 굵게 표시되며 링크는 파란색으로 표시됩니다. 코드는 회색입니다.

훌륭합니다! 그러나 MathJax 구분 기호 안에서도 해제해야합니다. 이러한 문제 중 일부는 이미 지적 되었지만 여기에서 명시 적으로 말할 것입니다. 이 스크린 샷 과 같은 서식을 엉망 으로 만드는 것은 매우 산만하고 전혀 쓸모가 없습니다 (응답하기 때문에 목표를 달성하지 못한다는 의미에서 하이 라이터가 생각하는 것 이외의 다른 출력을 생성 할 구문에 대한 것입니다.) 그리고 2020 년대는 말할 것도없고 2010 년대에는 수학 편집기에서 자리가 없습니다.

Answer 3

기능 요청

마크 다운을 리치 텍스트 와 동시에 볼 수 있도록 허용

수년 동안 우리는 미리보기를 최적화하여 화면의 많은 공간을 차지하지 않도록 할 수 있는지에 대해 많은 질문을 받았습니다. 긴 게시물을 작성한 적이 있다면 미리보기 끝에서 편집 창으로 돌아 가기 위해 스크롤을 많이하는 느낌에 익숙 할 것입니다. 새 편집기를 사용하면 Markdown 토글을 사용하여 Markdown과 서식있는 텍스트 모드 사이를 전환하여 미리보기를 볼 수 있으며 서식있는 텍스트 미리보기는 편집기의 일부이므로 편집 창을 찾을 필요없이 미리보기에서 바로 편집 할 수 있습니다. 다시. 이것은 짧은 포스트를 스크롤하는 것이 많은 작업을 의미 할 수있는 작은 화면으로 인해 모바일 사용자에게도 훨씬 더 편리합니다.

자주 묻는 질문 (faq)을 편집 한 사람이 여기에 자주 게시하기 때문에 여기에 대한 감정을 확실히 이해합니다. 편집하는 데 많은 시간을 할애 한 부분은 포스트 에디터 아래의 미리보기와 에디터 자체 사이를 앞뒤로 스크롤하는 것이 었습니다.

그러나 새 편집기는 원시 Markdown을 보는 동시에 텍스트의 렌더링 된 출력을 보는 기능을 제거합니다 . 게시물을 입력하는 동안 고급 Markdown 기술과 미묘한 뉘앙스 (및 가끔 HTML) 를 자주 사용하는 사람으로서 , 내 게시물이 어떻게 보이는지보고 싶을 때마다 계속해서 스위치를 앞뒤로 전환 해야하는 것은 단순한 작업에 비해 극도의 부담입니다. 스크롤.

이것은 또한 현재 미리보기에서 렌더링 된 출력이 게시 될 때 사용하는 전체 페이지에 많은 공간을 차지했기 때문에 매우 중요합니다 (투표 버튼에 대한 왼쪽 여백이 없기 때문에 약간 적음). 내 게시물의 길이를 대략적으로 파악하여 너무 길면 다시 조정할 수 있습니다 (예 : 불필요한 세부 정보 제거). 새로운 미리보기는 게시물이 게시 될 때 실제 페이지에 얼마나 오래 있을지 예측하는 것을 훨씬 더 어렵게 만듭니다. 다시 말하지만 스크롤해야하는 것을 참을만큼 자주 사용합니다.

다시 말하지만, 현재 새 편집기가 디자인 된 방식에 대한 감정을 완전히 이해합니다. 많은 사람들, 특히 큰 게시물의 경우 스크롤해야하는 작업이 상당히 어려울 수 있습니다 (예 : 여기에서 FAQ). 그러나 나는 새로운 설정이 나를 더 어렵게 만드는 현재 설정에서 가능하게하는 더 고급 기능을 자주 사용하는 사람입니다 .

편집기에 원시 Markdown을 입력 할 때 동시에 게시물의 실시간 렌더링 미리보기를 볼 수있는 옵션이 있습니까? 이것은 현재 게시물 아래에있을 필요는 없지만 이것을 고려하십시오.

---

나는 팀의 일원으로서 꽤 오랫동안이 편집기에 액세스 할 수 있었다는 점에 유의해야합니다. 이 새로운 워크 플로에 익숙해 지려고 여러 번 시도했지만 여전히 만족스럽지 않습니다.

또한이 답변을 조사하는 사람들 은이 게시물의 주장을 확장하는 Tinkeringbell이 작성한 두 가지 추가 답변 을 볼 수도 있습니다 .

Answer 4

기능 요청 상태 검토

모든 사용자가 '링크 선택'버튼의 작동 방식을 이해할 수 있을지 모르겠습니다. (힌트 : 먼저 텍스트를 선택해야 버튼이 활성화됩니다.) 정기적으로 사용하는 다른 서식있는 텍스트 편집기에는 표시 할 링크와 텍스트를 모두 지정할 수있는 '링크 삽입'버튼이 있습니다.

그래서 다음과 같습니다 (나쁜 모형을 용서하십시오. 아이디어가 분명하기를 바랍니다) :

또는 항상 버튼을 활성화하고 아무것도 선택하지 않은 경우 사용자에게 링크 (예 : 현재 편집기)를 요청하고 삽입하여 사용자가 링크 텍스트와 링크 자체를 모두 편집 할 수 있음을 알 수 있도록 팝 오버를 표시합니다.

Answer 5

기능 요청

기술적 한계로 인해 나란히 미리보기를 할 수 없다면 마크 다운 미리보기를 위해 리치 텍스트 모드보다 더 나은 대안이 필요합니다 . MD 편집기 아래에 라이브 미리보기 창을 두는 다른 설정이나 토글 (지금 미리보기가 작동하는 것처럼)조차도 MD와 RT 편집기 사이를 전환하는 것보다 훨씬 낫습니다 .

나는 게시물을 작성할 때 현재의 실시간 미리보기를 많이 사용합니다. 보통 크기의 화면에 보통 크기의 게시물을 작성할 때 편집기 대신 실시간 미리보기를 주시 합니다. 시간의 90 % 이상 , 아마도 위로 스크롤하고 미리보기에서 눈을 뗄 수 있습니다. 이미지와 대화 상자에서 확인을 요청하거나 paragaph에 다른 문장을 추가하기로 결정했습니다. 내 일상적인 워크 플로에는 사이트를 아래로 스크롤하여 실제로 편집기를 많이 보는 동안 라이브 미리보기를 보는 것이 포함됩니다.

이 게시물은 RT 편집기가 현재 배열보다 더 나을 수있는 한 가지 이유는

새 편집기를 사용하면 Markdown 토글을 사용하여 Markdown과 서식있는 텍스트 모드 사이를 전환하여 미리보기를 볼 수 있으며 서식있는 텍스트 미리보기는 편집기의 일부이므로 편집 창을 찾을 필요없이 미리보기에서 바로 편집 할 수 있습니다. 다시. 이것은 짧은 포스트를 스크롤하는 것이 많은 작업을 의미 할 수있는 작은 화면으로 인해 모바일 사용자에게도 훨씬 더 편리합니다.

게시물이 어떻게 보일지 대략적인 아이디어를 얻기 위해 두 편집기 모드 사이를 전환하는 것은 작성중인 내용 의 실시간 미리보기 가 아닙니다 . 쓰기 속도가 느려집니다. 그리고 "미리보기에서 바로 편집 할 수 있습니다"라는 말은 사실이 아닙니다. RT 편집기에서 작업하는 경우 편집기와 미리보기로 동시에 사용하는 경우 Markdown에서 계속 쓸 수 없습니다. . 다시 전환해야 "미리보기"가 사라집니다. 솔직히 이것은 이상적이지 않습니다. 스크롤이 적지 만 라이브 도 아닙니다 . 그리고 RT 편집기는 현재 실시간 미리보기보다 게시물이 어떻게 보이는지 보여주는 데 더 나쁜 역할을합니다.

나는 모바일 글쓰기를위한 RT의 아이디어를 좋아합니다. 전화 키보드를 볼 때 별표, 하이픈 및 해시 태그 가 한 번의 클릭으로 표시되지 않기 때문에 전화에서 MD를 거의 사용 하지 않습니다 . 하지만 지금은 대부분 컴퓨터에 게시물을 작성하고 있습니다 . 즉, 제 손에는 키보드가 있고, 제가하고있는 일 을 실제로 보여줄 수있을만큼 큰 화면이 있습니다.

이 전체 게시물은 지금 내 화면에 쉽게 맞습니다. 그리고 미리보기는 라이브이고 제가 소중히 여기는 것입니다. 이 글을 더 쉽고, 빠르고, 더 상호 작용하고, 더 유창하게 작성할 수 있습니다. 당신이 무엇을하든, Markdown 편집기를 사용하여 작성하는 사람들을 위해 우리의 라이브 미리보기를 빼앗기지 마십시오. 리치 텍스트 편집기 는 실시간 미리보기 가 아니며 , 두 중단 흐름 사이를 전환하며, 실시간 미리보기에서 허용하는 결과를 보는 동안 편집기가 리치 텍스트 모드에있는 경우 Markdown을 작성할 수 없습니다.

Answer 6

버그 상태 계획

이 마크 다운 :

# one heading

## two heading

### three heading

#### four heading

##### five heading

###### six heading

리치 편집기에서이 미리보기를 렌더링합니다.

다음과 같이 게시됩니다.

Answer 7

버그 상태 계획

기울임 꼴에 별표를 사용하지만 * 이와 같이 종료하지 않으면 미리보기에 기울임 꼴로 나머지 줄이 표시되지만 렌더링 된 게시물은 그렇지 않습니다.

Answer 8

기능 요청

Sonic은 이미 미리보기 기능을 놓친 것에 대해 썼습니다 . 저도 그렇습니다.하지만 미리보기를 놓친 이유가 더 있습니다. 그중 두 가지는 이미 알려진 문제입니다.

모드 간 전환은 대략적인 스크롤 위치를 유지하지만 커서가 어디에 있는지 기억하지 못합니다. 전환 할 때마다 커서는 현재 위치에 머 무르지 않고 게시물 상단으로 다시 이동합니다. [...] 서식있는 텍스트 미리보기는 Markdown을 해석하므로 서식있는 텍스트 편집기에서 잘못된 Markdown (MD)을 이스케이프 처리 할 수 ​​있습니다. MD보기로 돌아 가면 이러한 오류를 수정할 수 있습니다.

Teams에서이 편집기를 몇 번 사용했지만 마지막으로 사용한 옵션을 기본값으로 저장 하기 때문에 여기서 설정하기를 기대하지는 않습니다 .

내 일반적인 작업 흐름은 다음과 같습니다.

1. Markdown에서 게시물 작성을 시작하십시오.
2. 미리보기를보고 어떻게 생겼는지 확인하세요.
3. 1-2를 여러 번 반복하십시오.
4. 게시하기 전에 미리보기를 마지막으로주의 깊게 살펴보십시오.

미리보기를보기 위해 스위치를 토글하는 데 익숙해 질 수 있다고 생각하지만 (스크롤 할 필요가 없음) 마지막으로 사용한 옵션이 저장되어 있다는 사실 때문에이 새 편집기를 사용하기가 너무 답답합니다.

보통 내 '1 단계'에는 미리보기를보기도 전에 꽤 큰 텍스트가 포함되어 있습니다. 그러나 제 4 단계는 내가 무언가를 게시 할 때마다 a.) 먼저 Markdown 모드로 돌아가거나 b.) 다음 게시물을 쓰기 시작할 때 편집기를 Markdown 모드로 되돌려 야한다는 것을 의미합니다. 그리고 저는 그 토글에주의를 기울이고 싶지 않고 글쓰기를 시작하고 싶습니다. 즉, 서식있는 텍스트 편집기에서 Markdown을 작성하는 부분을 자주 실행 한 다음 현재 Markdown을 이스케이프하는 모든 슬래시를 전환하고 삭제해야합니다.

프로필 설정과 같이 수행 할 수있는 작업이 있습니까? 즉, 항상 마크 다운 모드에서 쓰기를 시작하고 '마지막 사용'설정을 무시하고 사이트 별 기본값을 무시할 수도 있음을 의미합니까?

Answer 9

"미리보기가 서식있는 텍스트보기로 축소되었습니다."

미리보기는 특히 일부 사이트에서 편집에 필요한 부분이며, 전체 게시물을보고 중복성을 위해 교정 할 수있어 매우 편리합니다.

Meta Stack Exchange에서 새 편집기를 활성화하면 다른 사이트 에서 편집기가 중단 됩니다.

예를 들어 Physics.SE에 대한이 질문을보십시오 : " 단일 연산자가이 벡터에서 어떻게 작용합니까? ". 여기에 텍스트를 복사하여 붙여 넣으면 미리보기없이 작성한 내용을 읽기가 더 어려울 수 있음을 보여줍니다.

동일한 텍스트를 Physics.SE 사이트의 답변에 복사하면 렌더링 문제가 나타납니다. 미리보기가 없으면 처음에는 명확하지 않습니다. 많은 추가 편집으로 이어집니다.

다음 스크린 샷을 참조하십시오 ( Meta Stack Exchange에서 활성화 된 편집기 ).

---

---

다음 스크린 샷을 참조하십시오 ( Meta Stack Exchange에서 편집기 비활성화 됨).

-

리치 텍스트 편집기를 활성화하면 활성화되지 않은 다른 사이트에서 어떻게 잘못 렌더링되었는지 확인하십시오.

Answer 10

기능 요청 상태 검토

표-이 버튼은 기본 3 행 2 열 표를 만들고 행과 열을 추가 / 제거 할 수있는 서식있는 텍스트 모드에서 특수 메뉴 옵션을 갖습니다.

테이블을 만들 때 (이후가 아닌) 행 / 열 수를 지정하는 방법이 있으면 좋을 것입니다. 예를 들어 Google 문서에서 :

Answer 11

(이 게시물의 형식이 고르지 않은 점에 대해 사과드립니다. 알파 테스트 편집기로 작성되었습니다. 마크 다운 모드에서도 "구문 강조 표시"기능이 너무 공격적이라는 것을 알게되었습니다. 마크 다운 모드인지 서식있는 텍스트 모드인지 확실하지 않습니다. 또한 마크 다운 모드의 구문 강조 표시가 부정확 한 것 같습니다. 예를 들어, 마크 다운 모드에서는이 게시물의 대부분의 텍스트가 현재 굵게 및 기울임 꼴로 표시됩니다. 다른 예를 들어, 처음에 아래에 세 개의 대시를 썼을 때 그 중 적어도 두 개는 리치 텍스트 모드로 작성되어 em 대시로 변환되었으므로 아래의 구분선은 처음에는 제대로 렌더링되지 않습니다.)

내 의견 에 EP의 대답은 이미 넘쳐있다, 그래서 내가 여기 계속하자. 나는 EP의 모든 답변에 강력하게 동의합니다. EP와 마찬가지로 이러한 제안 된 변경 사항 뒤에 악의적 인 의도가 없음을 이해하고 모두가 선의로 여기에 있음을 이해합니다.하지만 그와 같이 상황이 나에게 무뚝뚝해야한다고 생각합니다. 무엇보다 저는 EP의 중심 논문에 동의합니다.

이것은 MathJax 관점에서 매우 놀라운 일입니다.

게다가 Rob이 지적했듯이 여기에서 제기 된 문제는 MathJax를 넘어 다른 많은 사이트 별 서식 지정 플러그인으로 확장 될 가능성이 높습니다 .

기본적으로 리치 텍스트를 생각할 때

MathJax 중심 사용자는 MathJax 중심이 아닌 사용자와 완전히 다른 사용 사례입니다.

EP의 답변과 내 의견에서 논의했듯이 MathJax 중심 사용자가 서식있는 텍스트 모드에서 게시물을 작성한다고 제안하는 것은 농담이 될 것입니다. 그러나 현재 예상대로 MathJax 중심 사용자는 여전히 서식있는 텍스트 모드에 의존하여 가난한 사람의 MathJax 미리보기로 사용 합니다. 즉, MathJax 중심 사용 사례를 통합하기 위해 리치 텍스트 편집기는 MathJax 프리 뷰어 로서도 달빛을 발할 것입니다. 이것은 끔찍한 생각입니다.

기본적으로 MathJax는 서식있는 텍스트 표현과 호환되지 않습니다.

MathJax는 Markdown과 같은 환경에서 작성되고 별도의 최종 출력으로 컴파일되도록 설계되었습니다. 따라서 MathJax 프리 뷰어는 리치 텍스트 편집기와는 완전히 다른 종류입니다. MathJax 프리 뷰어 이기도 한 서식있는 텍스트 편집기를 만드는 것은 문제를 요구 하는 것입니다. 특히 MathJax 비즈니스가 나중에 고려 될 때 특히 그렇습니다. EP의 답변에 대한 내 의견에서 논의했듯이 많은 사람들이 이것을 시도했지만 실패했습니다. 이렇게하려고하면 결국 손을 들고 MathJax를 완전히 지원하는 것을 중단 할 것으로 예상됩니다. 그런 다음 위의 의견 에서 언급 한 일종의 폭동으로 돌아갑니다 (처음에는 실수로 작성되었습니다. Markdown 모드는 전혀 없지만 이와 같은 시나리오에서 동일하게 적용 할 수 있음을 이해합니다. 확실하게:

MathJax가 완전히 지원되지 않으면 MathOverflow가 계약 옵션을 사용하여 Stack Exchange 네트워크를 탈퇴 할 가능성이 높으며 Math Stack Exchange와 같은 사이트도 마찬가지로 불만족 스러울 것입니다.

솔루션 : 이러한 이유로 내가 보는 유일한 솔루션은 다음과 같습니다.

서식있는 텍스트 편집기에 의존하지 않는 Markdown 모드에 대한 전용 미리보기가 필요합니다.

이 전용 미리보기는 MathJax를 완전히 지원해야합니다. 마찬가지로 chess , go , furigana 및 music notation 과 같은 다른 사이트에서 사용되는 플러그인을 지원해야합니다 . MathJax와 이러한 플러그인의 공통점은 특히이 리치 텍스트 표현이 게시 된 출력의 미리보기로 작동해야하는 경우이를 완벽하게 지원하는 리치 텍스트 표현을 생성하는 것이 불가능하다는 것입니다.

핵심은 다음과 같습니다.이 솔루션에 필요한 미리보기 유형의 요구 사항은 이미 충족되었으며 현재 실시간 미리보기에 의해 초과되었습니다. 따라서 이러한 미리보기는 100 % 실현 가능하며 남은 유일한 질문은 Stack Exchange가 미리보기를 (재) 구현하여 이러한 커뮤니티를 지원할 의사가 있는지 여부입니다.

---

다음은 몇 가지 추가 생각입니다.

여기 에서 논의한 바와 같이 , 현재의 리치 텍스트가 아닌 편집기에 존재하는 라이브 미리보기가 지속적이고 자동으로 새로 고침되기 때문에 어떤면에서 많은 LaTeX 편집기보다 업그레이드된다는 데 동의합니다. 새로 고침을 너무 자주하거나 자동으로 할 필요는 없지만 좋은 일입니다.

Markdown 모드에 실시간 미리보기가없는 경우 몇 가지 이유로 리치 텍스트 모드로 전환하지 않고 표준 LaTeX 편집기에서와 같이 "컴파일"버튼을 눌러 볼 수있는 어떤 형태의 미리보기를 선호합니다.

1. 내가 본 리치 텍스트 편집기에서 MathJax 또는 Latex가있는 경우 MathJax는 게시 전에 완전히 렌더링되지 않습니다 (예 : 사용자 정의 매크로를 렌더링하지 못할 수 있음). 이에 대한 좋은 이유가 있습니다-MathJax / LaTeX는 작성중인 문자와 출력 될 문자 사이에 일대일 대응이있을 것이라는 이해로 설계되지 않았으므로 작성하기가 불가능합니다. 서식있는 텍스트 표현을위한 이러한 서신.

2. 이 이유와 다른 이유 때문에, 리치 텍스트 표현에서 보는 내용이 내가 게시 할 때 보게 될 내용을 적절하게 반영한다고 믿지 않습니다. 이로 인해 게시하기 전에 오류를 포착하기가 어렵습니다.

3. 미리보기 목적으로해야 할 모드 사이를 자주 전환하는 것은 번거 롭습니다 (EP의 답변과 내 의견에서 논의 된 이유로 Markdown 모드로 독점적으로 작성하고 서식있는 텍스트 모드로 미리보기합니다).

4. 번거로운 이유 중 하나는 모드를 전환 할 때 시간 지연이있을 것으로 예상하기 때문입니다.

5. 번거로운 또 다른 이유는 모드를 전환 할 때 전체 인터페이스가 다시 실행되는 것처럼 느껴질 것으로 예상되기 때문입니다. 이는 제가 작성한 내용을 미리 보는 것뿐 일 때 삐걱 거리는 효과입니다.

6. 서식있는 텍스트 인터페이스는 사용자가 전체적으로 서식있는 텍스트 모드로 게시물을 작성하고 해당 관점에서 인터페이스를 사용하는 방법을 배우고 있다는 가정하에 설계되었을 수 있지만 미리보기 전용으로 서식있는 텍스트 모드를 사용하기 때문에 의도 한 것과 완전히 다른 사용 사례가 될 것입니다. 이러한 방식으로 인터페이스를 배우고 사용할 때 미리보기 전용으로 서식있는 텍스트 모드를 사용하는 MathJax 중심 사용자에게 실망스러운 경험이 될 것으로 예상합니다.

7. 길이에 관계없이 게시물을 작성할 때 서식있는 텍스트와 마크 다운 콘텐츠 사이를 전환하려면 위로 스크롤하여 전환 버튼에 액세스해야합니다. 모드 간을 자주 전환하고 Markdown으로 작성하고 서식있는 텍스트 모드로 미리보기해야하는 예상 사용 사례에는이 작업이 번거 롭습니다. 우선, 내가 쓰고있는 글에서 자리를 잃고 모드를 전환 한 후 다시 찾아야합니다. 토글하기 위해 위로 스크롤 할 때 편집기 스크롤이 아닌 브라우저 스크롤을 사용하고 있는지 확인해야하기 때문에 두 배로 짜증이납니다.

Answer 12

기능 요청 상태 계획

나는 어떤 형태로든 Markdown과 미리보기를 동시에 볼 수 있도록 요청을 진심으로 지원합니다 . 가능하다면이 대신 어떤 식 으로든 그렇게하는 것이 좋습니다. 하지만 그렇게 할 수 없다면 ...

마크 다운과 서식있는 텍스트간에 전환하여 아무것도 편집하지 않고 결과를 미리 보는 것은 파괴적인 작업 이어서 는 안됩니다.

CM 중 한 명은 다음과 같이 언급했습니다 .

내 MD로 RT를 망칠 위험을 감수 할 수 없기 때문에 말 그대로 Teams에서 내 게시물을 미리 보지 않습니다.

사용자가 경우 에만 마크 다운 및 서식있는 텍스트 사이를 전환, 변경하지 않고 (예를 들어, 미리보기를 볼 수 있습니다) 다음 토글 다시는 기억하고 정확한 이전 상태를 복원해야합니다. 둘 사이에 1 : 1 대응이있을 수 없으며 서식있는 텍스트보기에서 무언가를 편집하면 반환시 다른 마크 다운이 발생할 수 있음을 이해할 수 있습니다.

그러나 "아무것도 변경하지 않음"을 특수한 경우와 반환시 사용자를 이전 상태로 되돌릴 수 있어야합니다. 그러면 서식있는 텍스트 편집기가 Markdown의 미리보기 역할을 할 수 있습니다.

Answer 13

버그 상태 검토

여러 단락 텍스트를 인용하면 단락 분할이 엉망이됩니다.

예

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam commodo turpis sapien, sit amet auctor felis vehicula at. Integer commodo vitae diam eget tristique. Vivamus au

Aliquam lobortis diam a dictum suscipit. Aliquam in lacus eu mi suscipit posuere et ac dolor. Vestibulum aliquet, ex eget molestie placerat, dolor mauris cursus libero, eget luct.

된다

> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam commodo turpis sapien, sit amet auctor felis vehicula at. Integer commodo vitae diam eget tristique. Vivamus au> u> Aliquam lobortis diam a dictum suscipit. Aliquam in lacus eu mi suscipit posuere et ac dolor. Vestibulum aliquet, ex eget molestie placerat, dolor mauris cursus libero, eget luct.t.

Answer 14

버그 상태 검토

1. 마크 다운 모드에서 시작
2. 텍스트 쓰기
3. Enter 버튼을 누르십시오.

편집자가 커서를 다음 줄로 가져갈 것으로 예상하지만 그렇지 않습니다. 커서를 움직이려면 Enter 키를 다시 눌러야하는데 단어 입력을 다시 시작하면 세 번째 줄 에 나타납니다 . 즉, Enter버튼이 작동하고 커서가 지연되는 것입니다.

Firefox 86에서는 재현 할 수 있지만 Chrome 88에서는 재현 할 수 없습니다.

Answer 15

버그 상태 검토

서식있는 텍스트 모드로 쓰기를 시작하고 '가로 규칙'버튼을 클릭하면 자동으로 선택되며 답안 상자 외부를 클릭해도 선택을 취소 할 수 없습니다. 따라서 입력을 시작하자마자 수평선이 사라집니다.

Answer 16

곤충

서식있는 텍스트 편집기는 HTML을 이스케이프하지 않지만 마치 이스케이프 된 것처럼 미리보기에 표시합니다.

예를 들어 다음과 같은 내용으로 게시물을 작성하는 경우 :

링크를 만들려면 <a href=”https://stackoverflow.com”> 여기 텍스트 </a>를 사용하세요.

그것은 <이것과>

다음과 같이 표시됩니다.

링크를 만들려면 여기에 텍스트를 사용하세요.

그것은

더 나쁜 것은 앞뒤로 변환하는 것이 부패한다는 것입니다. 이스케이프 된 HTML 엔티티로 시작하여 이스케이프되지 않은 HTML로 이동 한 다음 (스마트 따옴표로 인해 유효하지 않은) HTML 청크를 제거합니다. 또한 따옴표 형식을 중단합니다.

(이러한 버그로 인해 새 편집기에서이 게시물을 작성할 수 없습니다.)

Answer 17

기능 요청 이미지 상태 계획

삽입 된 이미지를 클릭 가능하게 만듭니다 (이전 편집기에서와 같이).

새 편집기는를 사용 ![](https://i.stack.imgur.com/HvbcS.png)하고 전자는 다음을 사용합니다.

[![enter image description here][1]][1]

  [1]: https://i.stack.imgur.com/HvbcS.png

삽입 된 이미지를 클릭 가능하게 만드는 것은 큰 이미지에 유용합니다.

Answer 18

버그 상태 검토

세 번 클릭하면 Markdown 모드에서 전체 텍스트가 선택됩니다.

한 단어를 선택하려면 두 번 클릭하고 단일 단락 을 선택하려면 세 번 클릭하는 것이 현대 텍스트 필드의 표준 관행입니다 . 이것은 이전 편집기에서 작동하고 서식있는 텍스트 편집기에서 작동하지만 Markdown 모드에서는 작동하지 않으며 대신 전체 텍스트가 선택됩니다.

Answer 19

버그 상태 계획

마크 다운 모드에서 구문 강조 표시는 * 이스케이프 된 별표 *에 대해 알지 못합니다. 이탤릭체로 된 사이에있는 단어 (후행 백 슬래시 포함)를 계속 표시합니다.

Answer 20

기능 요청 상태 검토

더 많은 표와 비슷한 기호를 가질 수 있습니까?

나에게 상단의 큰 필드는 그 아래에 버튼이있는 계산기 디스플레이를 생각 나게합니다. 제목 행의 열을 병합 한 테이블을 사용한 적이 없습니다.

Answer 21

기능 요청 버그

이미지 및 링크 도구는 이제 참고 문헌 형식이 아닌 인라인으로 이미지 및 링크를 추가합니다. 후자는 여전히 작동하지만 수동으로 만들어야합니다.

먼저 : 아직 작동하지 않습니다.

참고 문헌 형식을 수동으로 추가 할 수 있도록 허용하려는 경우 편집기 모드를 전환하지 마십시오 (서식있는 텍스트 편집기와 미리보기를 보는 다른 방법을 얻지 않는 한 : D).

---

둘째, Markdown의 인라인 링크와 이미지를 기본값으로 설정하면 워크 플로가 중단됩니다. 나는 참고 문헌을 시작하기 때문에 연구 기사에 대한 링크가 많은 긴 게시물에서 '링크'버튼을 많이 사용했습니다. 참고 문헌 형식을 사용하면 특히 동일한 게시물에서 동일한 게시물이나 기사를 여러 번 재사용 / 인용하는 경우 저작자 표시를 더 쉽게 제공 할 수 있습니다. 그냥 타이핑 만하면 [text][number of link to reuse]됩니다. 인라인 링크의 구문은 기억하기 쉽지만 이러한 종류의 재사용을 허용하지 않습니다.

'이전'편집기의 참고 문헌 형식의 또 다른 큰 이점은 다음과 같은 이미지를 추가한다는 것 [![enter image description here][1]][1]입니다.. 이 FAQ에서 설명하는 것처럼 이미지를 다른 사이트로 하이퍼 링크하는 것이 훨씬 쉽습니다 . 두 번째 번호를 변경하고 게시물 하단의 참고 문헌 목록에 다른 항목을 입력하십시오. 현재 편집기는 ![enter image description here](https://i.stack.imgur.com/RRHYf.jpg)형식을 사용하여 이미지 를 삽입합니다. 추가 하이퍼 링크를 삽입하려는 경우 빠르게 지저분 해지는 형식입니다. 방법을 외우려면 훨씬 더 많은 시간이 필요합니다.

그리고 링크가 많은 긴 게시물에서 게시물의 맨 아래에두면 잠재적 인 편집자의 작업이 좀 더 멋지게 만들어집니다. 특히 사용 된 링크가 긴 경우 더욱 그렇습니다.

이 결정이 왜 내려 졌는지는 모르겠지만 제 생각에는 게시물이 깔끔하지 않고 지저분합니다. 메타에 대한 서지 형식에 어려움을 겪는 사람들의 지원 질문이 많지 않아서 '사용 편의성'에 대한 질문이 아니라고 생각합니다. Rich Text 편집기는 Markdown 작성에 어려움을 겪는 사람들을위한 것이지만, 해당 편집자는 Markdown에서 링크가 작성되는 방식을 신경 쓰지 않으므로 그런 사람들은 알 필요가 없습니다.

따라서 링크와 이미지 모두에 대해 인라인 링크에 대한 기본값을 다시 고려해 주시기 바랍니다.

Answer 22

기능 요청 상태 계획

코드 블록의 언어를 쉽게 변경하는 기능을 추가합니다.

이것은 내가 믿는 다른 답변에서 언급되었지만 어떻게 작동하고 보일 수 있는지에 대한 아이디어를 위해 모의 UX를 추가하고 싶습니다.

언어 옆에 화살표를 추가하여 선택기처럼 보이게했습니다.

언어를 클릭하면 선택 가능한 대화 상자가 나타납니다. 예를 들어, 다음과 유사한 목록입니다.

✓ auto
-------
c#
css
html
javascript
plaintext
python

---

또 다른 아이디어는 이미지의 세부 사항 대화와 유사한 대화를 보여주는 것입니다. 이것은 성 가실 수 있으며 위의 옵션을 훨씬 선호합니다.

Answer 23

버그 상태 계획

리치 모드에서 스포일러에는 "Reveal Spoiler"텍스트가 없습니다.

Answer 24

버그 상태 검토

1. 텍스트 입력

2. 무언가 붙여 넣기

3. Ctrl/Cmd+를 누릅니다.z

4. 붙여 넣은 "일반 텍스트"가 아닌 입력 한 텍스트가 취소되는 것을 확인하세요.

Answer 25

버그 / 기능 요청 상태 검토

_{이것이 버그로 분류되는지 확실하지 않지만 항상 작동하고 새 편집기에서 작동하지 않는 것입니다.}

그래서 대부분의 텍스트 필드에서 작동 하는 맞춤법 / 문법 검사기 Chrome 확장 프로그램 을 사용하고 있습니다. 이전 편집기, 새 서식있는 텍스트 편집기에서 작동하지만 어떤 이유로 마크 다운으로 전환 할 때 작동하지 않습니다.

이 확장 기능이 게시물 작성 (특히 편집)에 정말 도움이 되었기 때문에 부끄러운 일입니다. 많은 작업이 Markdown 모드에서 수행됩니다.

이 문제를 해결할 수 있습니까? 아니면 새 편집기가 게시 될 때까지 기다린 다음이 "버그 보고서"를 Grammarly에 가져 가야합니까?

최신 정보:

Chrome의 개발자 도구에서 요소를 확인하면 마크 다운 텍스트가 <code>태그 로 래핑되어 있음을 알 수 있으며 그 원인 일 가능성이 있습니다.

<pre class="s-code-block markdown">
    <code>test</code>
</pre>

Answer 26

기능 요청 상태 검토

이전 편집기에서를 누르면 CtrlL다음이 표시됩니다.

새 편집기에서 누르면 [text](https://www.stackoverflow.com/). 여기에 링크를 붙여넣고 링크 와 설명이 아닌 링크 설명을 편집 할 수 있기 때문에 키보드 단축키를 누를 때 새 편집기에이 팝업을 표시하고 싶습니다 .

Answer 27

버그 상태 검토

사용하여 멋진 키보드 버튼을 추가하려면 <kbd>X</kbd>

X

그들은 풍부한 서식으로 완벽하게 표시되지만 X 뒤에 커서를 놓으면 kbd 요소 안에 입력하게됩니다. 같은 줄에 아무것도 입력 할 수 없습니다. 두 번 클릭하여 커서를 강제로 표시하지도 않습니다 (MS Word에서 작동하는 것처럼).

복제 단계 :

• 마크 다운 모드에서 시작

• 다음 텍스트를 추가하십시오.

  <kbd>X</kbd>
  

• 서식있는 텍스트 모드로 전환

• kbd 요소 안에 커서를 놓으면 편집 할 수 있지만 커서가 갇혀 요소를 떠날 수 없습니다.

Answer 28

버그 상태 완료

초안을 삭제해도 두 모드 모두에서 편집기가 지워지지 않습니다.

1. 답을 입력하세요.

2. 초안이 저장되고 Discard버튼이 나타날 때까지 기다리십시오 .

3. 를 클릭하십시오 Discard.

4. 평소와 같이 "초안 삭제됨"이라고 표시되지만 텍스트는 편집기에 남아 있습니다.

5. 페이지에서 나 가려고하면 "변경 사항 없음"에 대한 경고 메시지가 표시됩니다.

Answer 29

상태 계획

네트워크 링크를 붙여 넣어도 리치 모드에서 자동으로 미리보기의 링크가되지는 않습니다.

마크 다운을 다시 켜고 끄면 링크가 올바른 형식으로 보입니다.

리치 모드에서 링크 붙여 넣기 :

마크 다운 모드로 전환 될 때 링크 :

마크 다운 모드에서 리치 편집기로 다시 전환 할 때 링크 :

Answer 30

버그 상태 검토

답변을 추가하는 동안 마크 다운 모드에서 텍스트를 복사하여 서식있는 텍스트 편집기 모드로 붙여 넣으면 텍스트가 코드 블록으로 붙여 넣어집니다. 차라리 마크 다운 모드에서 텍스트가 서식없이 클립 보드에 복사됩니다.

Firefox를 사용하고 있지만 이것이 다른 곳에서 재현 가능한지 확실하지 않습니다.

---

Ctrl/ Cmd+ C다음 선택

Ctrl/ Cmd+ V서식있는 텍스트 편집기 모드에서