هل سيكون من الصعب استبدال محرر المنشورات الافتراضي textarea بمميز صيغة ماركداون؟
أم أنني أفتقد الخيار في مكان ما؟
لقد قمت بالفعل بتطبيق هذا بشكل جميل لـ CSS في محرر أنماط المسؤول:
3 إعجابات
أليس هذا قد تم تحقيقه بالفعل باستخدام كتلة التعليمات البرمجية، والتي تمنحك تمييزًا نحويًا في منطقة المعاينة؟
إعجاب واحد (1)
هذه فكرة مثيرة للاهتمام، سيكون الهدف هو تمييز الصيغة في مربع النص (أي الجانب الأيسر من المنشئ) حتى تتمكن من رؤية ما إذا كنت ترتكب أي أخطاء في صيغة الماركداون. نعم، كتل التعليمات البرمجية تفعل الشيء نفسه في المعاينة، ولكنك لن ترى أي أخطاء في الماركداون، على سبيل المثال. وبعض الماركداون المعقد سيكون أسهل في المسح، والنشر مع الكثير من الجداول، والتحميلات، والروابط، والعناوين.
لست متأكدًا من سهولة القيام بذلك، على الرغم من ذلك. تستخدم شاشات المسؤول لدينا محرر ACE، ولا أعتقد أنه يمكننا ببساطة سحب وإسقاط ذلك على منشئ المنشور.
4 إعجابات
نعم، هذه هي حالة الاستخدام الخاصة بي بالضبط.
إنه يعطي ملاحظات مباشرة جدًا حول بناء الجملة الخاص بك: ليس عليك النظر إلى اللوحة اليمنى كل ثانية للتحقق مما إذا كنت لا ترتكب أخطاء بناء جملة تافهة.
سيمنح المزيد من الهيكلية لأولئك الأقل مهارة في Markdown (أي مبتدئ).
بالطبع لا يزال لديك HTML المعروض على الجانب الأيمن من نافذة المنشئ.
لن أرى أي عيوب فورية في هذا، خاصة إذا كان خيارًا.
ملاحظة: على ما يبدو، لا يوجد حتى مُبرز لبناء جملة Markdown مثبت لـ codeblocks 
:
# بناء جملة Markdown codeblock...
... للأسف ...
- ليس
- مُبرزًا
**على الإطلاق**!
تحرير بعد ساعتين: تم الإصلاح بواسطة @pmusaraj
4 إعجابات
أوه، ملاحظة جيدة! يبدو أننا نفتقد بعض الأنماط لمميز ترميز ماركداون.
إعجابَين (2)
هل استخدام محرر كامل الميزات لـ “مجرد” ماركداون ليس مبالغًا فيه بعض الشيء؟
في رأيي، استخدام محرر شبه مرئي (semi-wysiwyg) للماركداون يتماشى بشكل أفضل مع احتياجات OP، مثل على سبيل المثال https://ui.toast.com/tui-editor، Milkdown إلخ.
3 إعجابات
كلاهما يبدو رائعًا!
ومع ذلك، يمكنني أن أتخيل أن Milkdown الأبسط سيكون مناسبًا بشكل أفضل نظرًا لأنه لا بأس إذا أعطى المحرر شعورًا أقرب إلى “شاشة تحت الماء” [1] نظرًا لأن لديك المعاينة على اليمين على أي حال.
نعم، أتذكر جيدًا WordPerfect
↩︎
3 إعجابات
نعم، أي واحد من ACE أو TUI أو Milkdown يمثل تغييرًا كبيرًا جدًا، وكلها ستحتاج إلى استبدال مربع النص بـ contenteditable. يستحق التجربة بالتأكيد، ولكنه مشروع كبير في جوهره.
4 إعجابات
PR جاهز مع إصلاح لتمييز markdown المفقود: UX: Update highlight.js styles by pmusaraj · Pull Request #23999 · discourse/discourse · GitHub
6 إعجابات
للتوضيح فقط، أولاً هذا شيء أريده حقًا أن يدعمه النواة الأساسية ولكنه يستحق أيضًا التوسع في التعقيد.
تستخدم نواة Discourse العديد والعديد من واجهات برمجة التطبيقات مباشرةً ضد TEXTAREA، @mentions، شريط الأدوات يُدرج أشياء في TEXTAREA، التحميلات، قص ولصق الصور والمزيد.
كل هذا ليس مجرد تجريد ويفترض أنه يتحدث إلى TEXTAREA. إضافة contenteditable هناك مباشرةً سيعني أنه سيحتاج أيضًا إلى محاكاة TEXTAREA بشكل صحيح ودقيق للغاية، وهو أمر من المحتمل أن يفشل. نحتاج إلى قدر كبير من العمل لإنشاء نوع من إطار عمل الموفر حتى نتمكن من تبديل الأشياء.
انظر أيضًا:
المميز بالتأكيد خطوة رائعة أولى في هذا الاتجاه لأنه لا يتعين عليك القلق بشأن تعيين markdown ثنائي الاتجاه إلى نص.
قد يكون هناك بعض الاختراق الخفي حيث يمكنك إخفاء TEXTAREA ثم عرض contenteditable فوقه، ونقل الأحداث إلى الأصل، ولكن حتى ذلك سيتطلب إعادة تنفيذ تحديد موقع @mention.
9 إعجابات
يجب أن أكون صريحًا هنا: الآن بعد أن رأيت محرر Trello، تشعر Discourse بأنها من حقبة 2000 فيما يتعلق بالجانب التحريري:
أعتقد أن هذا النوع من الأشياء مهم.
ملاحظة: لا يزال يقبل بناء جملة Markdown بنسبة 100%.
إعجاب واحد (1)
شخصيًا لست من محبي هذا. إنه مزدحم للغاية. أحب أن المحرر في Discourse نظيف بصريًا. كل ما أراه حقًا هو النص، والأشياء المعروضة في الجانب حيث تنتمي.
بالعودة إلى النقطة الرئيسية لإبراز الصيغة، هذا شيء أود رؤيته أيضًا. على الأقل، أود أن يتم إبراز # العناوين و ## العناوين الفرعية بطريقة ما. لا يمكنني أن أخبرك كم مرة أبحث في مشاركاتي الأطول، حيث يكون المعاينة والمحرر غير متوافقين، ويستغرق الأمر وقتًا طويلاً للعثور على # العنوان ذي الصلة.
بالنسبة لي، مجرد جعل # العناوين بخط عريض، أو بلون معين في جانب المحرر من المنشئ سيكون تحسينًا هائلاً.
إعجابَين (2)
إنها كذلك، أليس كذلك؟
تم تصميم محررات النصوص هذه للمطورين والمبرمجين وهي مربكة حقًا للمستخدمين العاديين.
لكن الأمر الواقع هو أنه لا يمكن تغييره لأنه متجذر بعمق في النظام الأساسي. مثل سؤال المسودة 
على أي حال - خارج الموضوع إلخ.
إعجاب واحد (1)
هل هذا أقرب إلى الحدوث؟
السياق:
إعجاب واحد (1)
لقد بدأنا العمل في هذا المجال، وستشارك @lindsey المعلومات مع تقدمنا
9 إعجابات
يسعدني سماع ذلك - يعد استخدام ترميز ماركداون رائعًا لمستخدمينا المتقدمين، ولكنه يمثل منحنى تعليميًا كبيرًا لمعظم مستخدمينا الأقل خبرة وسيقطع شوطًا طويلاً في جعل مجتمعنا أكثر سهولة في الوصول إليه.
4 إعجابات
مرحباً @lindsey، لا أريد أن أستعجلك بأي شكل من الأشكال، لكنني اعتقدت أنني قد أسألك عما إذا كان بإمكانك مشاركة ما يلي:
-
ما إذا كانت التغييرات ستشمل قابلية التشغيل البيني / إطار عمل للسماح للمكونات الإضافية بتطوير حلول للمحرر.
-
وبالمثل، ما إذا كنت تفكر في تطوير محرر نصوص منسق خاص بك، على سبيل المثال في مكون إضافي.
-
فكرة تقريبية عن الجدول الزمني الذي تفكر فيه للنقطة 1 و / أو 2.
السياق بالنسبة لي هو النهج والجدول الزمني لهذا المشروع المحتمل
أنا و @Rohail_Altaf نحاول التفكير في أفضل طريقة للتعامل مع هذا، خاصة من حيث الجدول الزمني. ومع ذلك، أتفهم تمامًا إذا لم تتمكن من مشاركة ذلك في هذه المرحلة.
5 إعجابات
مرحباً أنجوس - آسف على التأخير هنا، لقد كنا في خلوتنا السنوية للشركة في طوكيو!
لا يمكنني الإجابة بالكثير من التفاصيل الآن لأننا ما زلنا نضع اللمسات الأخيرة على تفاصيل التنفيذ. أعتقد أنه يجب أن نكتشف ذلك في الأسابيع القادمة، على الأقل بما يكفي للإجابة على هذه الأسئلة، لذا سأعود للتحقق بمجرد أن نعرف المزيد.
6 إعجابات
تُصدر Discourse الآن مُحرر WYSIWYG تجريبي 
هذه البنية التحتية تجعل من الممكن على المدى الطويل تطبيق تمييز بناء الجملة على Markdown إذا أردنا السير في هذا الاتجاه، ولكنها تصبح أقل ضرورة بكثير مع المُحرر الجديد.
على سبيل المثال، يسمح لك المُحرر الجديد الآن بتطبيق تمييز بناء الجملة على الكود أثناء كتابته!
5 إعجابات