الخط أحادي المسافات في محرر Markdown-only

هدفي ليس التركيز على “لنضف أو نزيل الخط أحادي المسافة”. أناس مختلفون، أذواق مختلفة.
أعتقد أنه عندما تقدم شركة شيئًا ما لفترة طويلة، إذا أرادت تغييره، فلا ينبغي أن يكون إلزاميًا، بل اختياريًا.

أنت تفضل استخدام ماركداون مع خط أحادي المسافة. جيد.

أنا أفضل استخدام ماركداون كما كان دائمًا بخط sans-serif. جيد.

لكنني الآن مجبر إما على استخدام النص المنسق، والذي لا أرى نفسي أستخدمه، أو استخدام إصدار جديد من ماركداون لم أستخدمه من قبل ولا يعجبني.

يجب تقديم ماركداون بخط sans-serif أو خط أحادي المسافة كخيار، بدلاً من إجبار جميع المستخدمين على التعود على شيء أظهر البعض منا بالفعل أنه لا يروق لنا.

تبرير هذا التغيير بأنه “بيئة برمجة” لا معنى له، لأننا لا نبرمج في المنشئ. نحن نكتب نصًا عاديًا وأحيانًا نقوم بتنسيقه باستخدام ماركداون. هذه ليست بيئة برمجة.

مرة أخرى، النقاش بالنسبة لي هو ما إذا كان الخط أحادي المسافة يجب أن يبقى أم لا. يتعلق الأمر بأن يكون لدي خيار اختيار ما يعجبني. وحل CSS البديل يعمل فقط لمجتمعي. ماذا عن جميع المجتمعات الأخرى التي تستخدم Discourse حيث أُجبر الآن على التغيير الجديد؟ لا معنى له بالنسبة لي.

4 إعجابات

بالفعل، بالنسبة لجميع المستخدمين في جميع المنتديات التي لم تقدم بعد الملحن الجديد، فإن الخط أحادي المسافة يمثل تغييرًا. وأعتقد أن هذا ليس أمرًا جيدًا.

3 إعجابات

ضع في اعتبارك أن هذا التغيير يسمح للمستخدمين بمعرفة أنهم في وضع الكود المصدري مقابل الوضع الغني بسرعة

قلقي بشأن التراجع هو أن هذا يحسن للمستخدمين الذين لا يريدون أبدًا استخدام محرر النصوص الغني وينفرون من التغيير، ألن يحقق خيار “لا يوجد نص غني بالنسبة لي” نفس الهدف؟

3 إعجابات

فقط إذا كانوا يعرفون هذا الاختلاف وماذا يفعلون لذلك. الوضع الغني متاح للأشخاص الذين لا يستطيعون القيام بـ **غامق**.

كل ما يرونه هو خط صعب.

ومرة أخرى - عندما يستخدم المسؤول الوضع الغني كوضع افتراضي، سيحدث ذلك فقط إذا نقر هذا المستخدم أو لمس المكان الخطأ، ولا يمكنه فهم ما حدث بحق الجحيم.

ومرة أخرى ثانية - الخط أحادي المسافة صعب على العين :man_shrugging:

لكن لدينا كل هذا

لا أعرف إذا كان

تمكين أحادي المسافة في وضع الكود المصدري (حقًا… تسميته بهذه الطريقة يكشف شيئًا :smirking_face:)

سيكون شيئًا فظيعًا (إذا كان من السهل بناؤه بشكل معقول).

3 إعجابات

… ويمكنهم بسهولة النقر على زر لإزالته :slight_smile: لذا يتم تشجيعهم على استخدام الخط “السهل” الذي يبدو رائعًا. يجب على 99.9٪ من المستخدمين اختيار ذلك للمؤلفات العادية.

أتفهم أن الناس يضغطون من أجل تفضيل المستخدم هنا، ونحن نناقش هذا داخليًا أيضًا. إنه أمر صعب، وعادةً ما نضيف التفضيلات كملاذ أخير، ربما تكون هذه إحدى تلك الحالات.

أيضًا… أنا لا أرى سلوكنا كحالة شاذة:

Reddit، الموقع رقم 6 على الإنترنت يفعل الشيء نفسه بالضبط:

لا يوفر خيارًا لتجاوز هذا…

5 إعجابات

ماذا عن إضافة؟

ثم يتعين على المسؤولين استثمار العمل بنشاط في هذه الميزة وستظهر أرقام الاستخدام ما إذا كان هذا الخيار مطلوبًا حقًا.

إعجاب واحد (1)

أنا فضولي - أيها سيجذب المسؤولين أكثر؟

  • مكون السمة - تغيير الخط عالميًا
  • المكون الإضافي - إعداد لكل مستخدم للخط
0 voters

نظرًا لأن مسار مكون السمة مفتوح جدًا، فأنا لا أفهم لماذا قد ترى تصويتًا عليه كتصويت ضد مكون إضافي.

إعجاب واحد (1)

إذًا الخيارات هي عندما يكون الخط مشكلة، ثم

  • لا تستخدم ترميز ماركداون، أو
  • استخدم هذا الخط الصعب

إذًا…

أعتقد أنه مطلوب عندما يمزج المنتدى بين الأمور المتعلقة بالمطورين والمناقشات الأكثر شيوعًا. إذا أراد مطور متشدد استخدام خط الآلة الكاتبة في كل مكان، أفهم ذلك، لكنني لا أفهم لماذا أُجبر على استخدام نفس الشيء.

لكن هذا وضع غريب إلى حد ما: نحن نكتب باستخدام خط واحد، لا يقدم أي فوائد، ولكنه يعمل كعلامة على نوع المؤلف الذي يستخدمه المستخدم، وبعد ذلك نقرأ ويكون الخط مختلفًا تمامًا.

أنت تعلم جيدًا أن هناك أمثلة معاكسة أكثر بكثير. ولست متأكدًا لماذا يجب أن يكون ريديت مثالًا جيدًا. إذا كان كذلك، فيجب علينا تكييف فيسبوك أيضًا.

إعجابَين (2)

لا يحتوي فيسبوك على وضع مزدوج. لا يمكنني التفكير في الكثير من القطع الأخرى التي تحتوي على وضع مزدوج، هل يمكنك تقديم بعض الأمثلة؟

CKEditor يفعل نفس الشيء الذي نفعله:

الكود المصدري في أحادي المسافة هو نمط راسخ جدًا.

… لديك ماركداون أسهل في التحرير

على سبيل المثال:

```
واحد
   اثنان
      ثلاثة
```

:up_arrow: تمرين عبثي في غير أحادي المسافة.

لأنك ترى

3 إعجابات

هذا ليس مهمًا. النقطة هي أنه إذا كنت تستخدم ريديت كمثال لتجربة مستخدم مفيدة، لأنه كبير، فيجب عليك استخدام نفس المنطق مع فيسبوك.

ريديت ليس شائعًا في الواقع خارج الولايات المتحدة والعالم الناطق باللغة الإنجليزية الأصلية.

إذا فهمت بشكل صحيح، فإن خط monospace الذي يصعب قراءته هو مؤشر لمحرر markdown؟ أليس هذا طريقًا قاسياً بعض الشيء؟ أولئك من مستخدمي، وأنا، الذين يستخدمون markdown، يعرفون المحرر المستخدم بغض النظر عن الخط.

مرة أخرى - CSS هو المنقذ. ولكن ليس هنا. في ميتا لدي خياران فقط:

  • أعاني من خط آلة كاتبة عمره 100 عام، لأن عددًا قليلاً من المواقع تستخدمه
  • عدم استخدام محرر markdown

إذًا… :man_shrugging: ربما يكون هذا الإعداد ضروريًا، لأنك لا تجبرني على استخدام القوائم الذكية أيضًا.

(خارج الموضوع، أعرف - لكن المستخدمين العاديين على مستوى المستهلك يحتاجون فقط إلى شريط أدوات بزر واحد: لتحميل الصور)

بعض المستخدمين مثلي لن يستخدموا النص المنسق أبدًا، لذا فهذه ليست ميزة تحدث فرقًا حقًا. إذا كان الإعداد الافتراضي لدي هو Markdown، فهذا كل ما أحتاجه “لأعرفه”.

بالتأكيد، هناك مستخدمون آخرون ربما لا يعرفون شيئًا عن Markdown والنص المنسق مفيد لهم. أفهم ذلك، مثل جميع المستخدمين الذين “ضد” التغيير. نحن لا نتجاهل هؤلاء المستخدمين. نحن نطلب خيارًا، وليس أمرًا إلزاميًا.

من التعليقات التي قرأتها، لا أحد ينفر من التغيير على الإطلاق. أنت تستخدم ذلك كذريعة للقرار الذي اتخذه الفريق. أنا لست منفرًا من التغيير، وأود أن أقول إن المستخدمين الآخرين في نفس القارب. نطلب أن يكون هناك تفضيل لأولئك الذين لا يريدون Markdown + monospace معًا.

هذا هو نفس الشيء. أنت تواجه صعوبة في فهم أن “لا نص منسق” و “لا نص منسق مع خط sans-serif” هما شيئان مختلفان، مع الأخذ في الاعتبار أن “لا نص منسق” الآن = خط monospace، وهو خط سيء.

أليس من “الصعب” أيضًا أن تجبر فجأة آلاف المستخدمين الذين يستخدمون المنتديات لسنوات، باستخدام Discourse، على التعود على شيء ثبت أنه ليس مثاليًا للقراءة؟

على سبيل المثال، تسمح Facebook و X/Twitter و YouTube بروابط قابلة للنقر في المنشورات. Instagram و TikTok لا تسمح بذلك.
كل شركة هي شركة. لمجرد أن Reddit أو CKEditor يعملان بطريقة معينة، لا يعني أنه يجب عليك نسخهما. عليك أن تفعل ما هو منطقي لمنتجك. ومرة أخرى، لا أحد يطلب منك إزالة النص المنسق أو خط monospace. نطلب أن يكون هذا خيارًا. يحب بعض الناس السمات الفاتحة، ويحب البعض السمات الداكنة. يحب بعض الناس خلفية سوداء خالصة مع نص نيون أثناء البرمجة، ويحب البعض الألوان الباهتة. كل شخص مختلف.
لا يجب أن يكون منطقيًا بالنسبة لك، بل يجب أن يكون منطقيًا للمستخدم.

لا أريد أن أبدو وقحًا أو أي شيء من هذا القبيل. أقدر Discourse كمنصة، خاصة لكونها مجانية لخيارات الاستضافة الذاتية. أجد صعوبة فقط في قبول أن فريقًا من الأشخاص، بما في ذلك المطورين، وما إلى ذلك، يواجهون صعوبة في قبول أن وجود تفضيل للمستخدم هو الطريق الصحيح، بعد ما يقرب من 4 أشهر من مطالبتنا بـ “تركه يتنفس”. لقد تركته يتنفس والكثير منا لا يحبونه ونريد على الأقل أن يكون لدينا خيار تحديد ما نريده استخدامه.

إعجابَين (2)

هذا هو جوهر سؤالي، هل سيكون

  1. لا تعرض لي محدد markdown / rich
  2. فقط أعطني markdown القديم الجيد
  3. اترك الخط كما كان من قبل

على سبيل المثال:

تفضيل المستخدم لوضع تأليف Markdown:

  1. قديم: تمامًا كما كان يعمل في الأيام الخوالي. نفس الخط نفس كل شيء. لا يوجد محدد RTE، لا يوجد RTE
  2. يفضل النص الغني: اجعلني افتراضيًا للنص الغني لكل مشاركة أكتبها
  3. يفضل Markdown: اجعلني افتراضيًا لتحرير Markdown

أحب هذا لعدة أسباب.

  • بالنسبة للإعدادات الافتراضية الجديدة للمنتدى، أعتقد أن وجود الكود المصدري بخط مصدري أفضل.
  • أحب أن يكون لدي إعداد صريح لـ “كيف أحب تأليف markdown”
  • مع إعداد صريح مقابل ضمني، فإنه يعيدني عند بدء مشاركة، وهو ما أفضل. لا أحب الذاكرة الضمنية.
3 إعجابات

لدي خيار ثالث: السماح لـ Discourse بالقيام بذلك بشكل أصلي. لطالما كان لدينا خطوط sans-serif ولا أعتقد أن ذلك كان مشكلة. إضافة المزيد من الإضافات للتثبيت والإدارة لا يبدو منطقيًا، على ما أعتقد.

ولكن من بين الخيارين، تبدو الإضافة منطقية أكثر، وإلا فإن الأمر سيان: نحن نجبر جميع المستخدمين على استخدام خط واحد، بدلاً من أن يكونوا قادرين على الاختيار، وهو ما أعارضه (الآن بعد أن أصبح لدينا خيار النص المنسق، بالطبع).

إعجاب واحد (1)

يمكن لمسؤول المجتمع تعيين الخط الافتراضي لـ markdown كـ sans-serif أو monospace. ثم يختار كل مستخدم ما يريد. إذا قام المسؤول بتعيينه إلى sans-serif، فسيشاهد المستخدم:

استخدام خط monospace في عرض markdown

إذا قام المسؤول بتعيينه إلى markdown، فسيشاهد المستخدم:

استخدام خط sans-serif في عرض markdown

لا حاجة لتعقيد الأمر بكلمات مثل “قديم” أو أي شيء متكلف. اجعله سهل الاستخدام ومباشرًا. فكر كمستخدم عادي، وليس كمطور.

4 إعجابات

همم، لقد فاتنا تمامًا هذه الضجة في مجتمع لغة البرمجة الخاص بنا على Discourse لأن (أفترض؟) أننا نعطل محرر النصوص المنسقة بالكامل. ربما تم اتخاذ هذا القرار في عام 2016، ربما عندما كان محرر النصوص المنسقة أكثر رداءة مما هو عليه اليوم. ثم لم يتم إعادة تقييمه أبدًا. أو ربما يسبق تثبيتنا تحرير النصوص المنسقة تمامًا ولم نقوم بتشغيله أبدًا. في كلتا الحالتين، لا نزال نرى السلوك “القديم” بخط serif في محرر markdown، وأنا سعيد جدًا بهذا السلوك.

بصفتي شخصًا يكتب شخصيًا الكثير من markdown والكود (في محررات monospaced وفي العديد من مربعات نصوص HTML)، لدي أفكار.

أفضل تمامًا استخدام خط serif في محرر غير مخصص للنصوص الغنية لكتابة منشورات Discourse. أنا متأكد من أن هناك بعض النفور من التغيير وراء ذلك، ولكن أعتقد أن هناك أيضًا بعض الأسباب الوجيهة. معظم النصوص التي أكتبها على Discourse و GitHub هي في الواقع نصوص، وليست كود. في الواقع، لن أصف markdown بأنه “كود” على الإطلاق! الوقت الوحيد الذي أريده لخط monospaced في نافذة محرر النصوص هذه (أو نافذة GitHub) هو داخل أسوار ``` ```` - لأن ***هذا*** هو الكود. لا تخلط بين markdown والكود؛ إنه ليس كودًا. وأنا أكره محررات النصوص المنسقة لأنها غالبًا ما تقاتل ضدي. على سبيل المثال، هذه الفقرة نفسها تحصل على بعض السلوكيات الخاطئة بشكل كبير بعد التخبط لكتابة markdown للسور (إنها مجرد ``` `````، ولكن الآن لا يمكنني لمس tilde على لوحة المفاتيح الخاصة بي دون إفساد محرر النصوص المنسقة).

تتوافق خطوط serif في محرر غير مخصص للنصوص الغنية أيضًا مع GitHub - الموقع الآخر الذي يحتوي على مربع نص HTML حيث أكتب الكثير من markdown.

أراهن أن هذا يمثل جزءًا كبيرًا من مجتمع البرمجة لدينا بشكل عام. الأشخاص الموجودون في لوحة Discourse الخاصة بنا:

  • يكتبون الكود المصدري ويستخدمون خطوط monospaced لكتابة الكود المصدري
  • يعرفون كيفية كتابة وقراءة markdown مباشرة
  • لا يعتبرون نص markdown كودًا مصدريًا
  • يفضلون على الأرجح استخدام محررات غير مخصصة للنصوص الغنية
  • يفضلون على الأرجح الكتابة / تحريرها كنثر - لذا بخط serif
7 إعجابات

هذا ليس هو الحال. من المرجح أنك لم تقم بالترقية إلى إصدار يتضمن محرر النصوص المنسقة.

3 إعجابات

لا يهم حقًا، أليس كذلك؟ لقد أزلت الهامش من منشوري الأصلي. النقطة المهمة هي أن محرر النصوص المنسقة في نسختنا معطل، وأنا سعيد بإبقائه معطلاً طالما أن تشغيله (في رأيي) سيؤدي إلى تدهور محرر ماركداون بهذه الطريقة.

image

إعجاب واحد (1)

أعتقد أن إعداد النص يصل إلى جوهر نقطة @alltiagocom — بالتأكيد لن أتوقع أن يغير مربع الاختيار هذا سلوك “وضع Markdown الحالي”. أفهم الرغبة في الحد من التفضيلات (وخاصة تفضيلات المستخدم) — إنها هدف جدير بالثناء حقًا! ولكن يبدو حقًا أن هذا شيء أسلوب متعامد من الأفضل أن تتعامل معه السمات بنفسها.

إعجابَين (2)

في CSS الخاص بي أين؟ أنا لست مسؤولاً، وهذا هو جوهر كلامي. إلا إذا كنت تقول إنه كمستخدم عادي يمكنني تجاوز CSS بطريقة ما (بدون استخدام إضافة للمتصفح).

ولكن هناك مفتاح تبديل حرفيًا يوضح الوضع الذي أنت فيه. ما الذي تحتاجه أكثر؟ من لقطة الشاشة الخاصة بك، أعتقد أنها غير مرئية على الهاتف المحمول، لذا اجعلها مرئية وسيتم حل هذه المشكلة.

هل تخطط لإزالة إصدار markdown في المستقبل؟ إذا كان الأمر كذلك، أفهم لماذا تريد دفع الأشخاص نحو هذا العرض. لكنني أريد أن أذكر مرة أخرى أن محررات WYSIWYG ليست مثالية أبدًا وغالبًا ما تكون غير متسقة. المشكلة الكبيرة هي أنه يتعين عليك تعلم غرائب محرر WYSIWYG على كل موقع/تطبيق محدد. تستخدم Teams و Confluence و Bitbucket كلها WYSIWYG ولكل منها غرائبها الخاصة التي يجب أن أتعلمها وأتكيف معها. لم أعتد على بعضها بعد لأنها تتعارض مع كيفية عمل مدخلات HTML العادية / مربعات النص، وكل غرابة تعني المزيد من الوقت الذي يجب أن أقضيه لكتابة ما أريده. من ناحية أخرى، يعمل Markdown دائمًا ويمكن كتابته أو تحريره يدويًا، مما يجعله أقل عرضة للخطأ.

أيضًا، بالنسبة لـ Discourse على وجه الخصوص، يحتوي برنامجك على مكونات أكثر بكثير مما تحتوي عليه المحررات البسيطة عادةً (استطلاعات الرأي، اقتباسات المشاركات، التفاصيل المخفية، المفسدات، إلخ) وهي أكثر تعقيدًا بكثير. أفهم أن وجود هذه العناصر مرئية في سطر واحد هو فائدة للمستخدمين غير التقنيين، ولكنه أيضًا المزيد من الأماكن التي يمكن لمحرر WYSIWYG أن يتعطل فيها بشكل خفي بطرق مزعجة للمستخدمين المتقدمين.

أعتقد أن Reddit لديه وظائف أقل تعقيدًا بكثير، مما يعني أنه من الأقل ضرورة استخدام محرر markdown. لقد لاحظت فقط التبديل للتبديل إلى وضع markdown مؤخرًا (وقمت بالتبديل فورًا بعد رؤيته أنه أحادي المسافة)، ولكن الفرق هو أنه على Reddit أحتاج فقط إلى سلوك أساسي مثل الخط العريض والمائل أو الروابط، وهو أمر جيد تمامًا في وضع WYSIWYG.

لا أعرف لماذا تستمر في استخدام مصطلح “الكود المصدري”. يبدو أنك تستخدمه لتقول إن ما نكتبه “يشبه الكود” وبالتالي فإن أحادي المسافة منطقي. لكنه في الواقع ليس شبيهًا بالكود على الإطلاق. Markdown ليس له علاقة بكتابة أو قراءة الكود على الإطلاق.

يستخدم Bitbucket نهجًا هجينًا حيث يمكنك رؤية markdown ولكنه يعرض أيضًا تأثير markdown. على سبيل المثال، سترى **text**، ولكن سيتم عرض النجوم و “text” بخط عريض في المحرر. يستخدمون خطًا serif لجميع النصوص التي ليست في كتلة كود، بينما يتم عرض النص داخل كتلة كود بأحادي المسافة. (ونعم، المحرر لديه غرائب تجعلني أخطئ بشكل متكرر عند تحرير تعليق.) لا يمكنني تقديم لقطة شاشة لأن لدي وصولاً فقط على جهاز العمل الخاص بي.

بالضبط! لم أسمع أبدًا مهندس برمجيات يقول “واو أتمنى حقًا أن يستخدم محرر markdown هذا خطًا أحادي المسافة”.

إعجابَين (2)