أعدتُ مؤخرًا منتدى Discourse خاصًا بي: https://crucible.hubbe.net/، وبشكل عام أنا راضٍ جدًا عنه. المجتمع مخصص لوحدة من نوع Arduino تُستخدم في الغالب لصانعي الديكورات (prop makers). ونتيجة لذلك، نستخدم قدرًا كبيرًا من أكواد C++ المُعدّة بقوالب. وعلى وجه التحديد، نستخدم شيئًا يُسمى “النمط” (style) الذي يحدد كيفية ظهور الأضواء. يمكن أن تكون الأنماط معقدة، لذا قمتُ بكتابة أداة معاينة وتحرير عبر الإنترنت، ثم استخدمتُ مكون الموضوع discourse-linkify لجعل الأنماط ترتبط تلقائيًا بالمحرر. وقد اضطررتُ لإجراء بعض التغييرات البسيطة على مكون الموضوع discourse-linkify لجعلها ترسل أحرف العناوين (URL characters) وما شابه، وهو أمر كان سهلًا نسبيًا، ويمكنني إنشاء طلب دمج (PR) لهذه التغييرات إذا كان هناك اهتمام.
ومع ذلك، هناك مشكلة…
بعض أكواد القوالب تبدو في النهاية أشبه بـ HTML بسبب كل أحرف < و>، وفي مرحلة ما يقوم Discourse بإزالة بعض هذه “العلامات”. بشكل أساسي، يبدو أن أي كلمة غير معروفة محصورة بين < و> يتم حذفها. السطر التالي في هذا المنشور سيكون < foo > ولكن بدون المسافات:
< - هنا يوجد foo
في البداية ظننتُ أن مكون linkfy هو من يقوم بشيء خاطئ، ولكن بعد بعض البحث، بدا أن المحتوى المفقود قد اختفى بالفعل قبل أن يعمل linkfy. لذا، أعتقد أن العلامات الإضافية تبخرت في مكان ما أثناء عملية المعالجة؟
لاحظتُ أنه في كتل الأكواد (المُحددة بثلاث علامات ` أو ما شابه) تبقى العلامات، ولكن لأغراضي، سيكون من الأفضل لو بقيت دائمًا.
لفترة من الوقت، ظننتُ أنه سيكون كافيًا تعديل CODE_BLOCKS_REGEXP في ملف discourse/lib/utilities.cs لجعل هذا يعمل، لكن inCodeBlock لا يُستخدم من العديد من الأماكن، لذا ربما هذا غير صحيح؟ أيضًا، لم أتمكن بعد من معرفة كيفية تعديل CODE_BLOCKS_REGEXP فعليًا من خلال مكون إضافة أو موضوع.
ما هو الكود المسؤول فعليًا عن إزالة هذه العلامات؟
ما هي أفضل طريقة (الأكثر دعمًا) لتعطيل ذلك؟
يجب أن أشير أيضًا إلى أنه نظرًا لأن الأشخاص ينسخون أحيانًا كتلًا كبيرة من الأكواد، فقد يكون من الصعب جدًا ملاحظة أن بعض الأجزاء في الوسط قد اختفت. وعلى أقل تقدير، سيكون من الأفضل تحويل الوسوم المجهولة إلى علامات تحذير واهتزاز أو شيء ما يخبر المستخدم بأن شيئًا غير متوقع قد حدث.
لأن لديّ أمورًا أفضل من ترويض القطط؟
إذا وُجدت طريقة سهلة وطريقة صحيحة للقيام بالأشياء، فسيختار الناس دائمًا الطريقة السهلة. أفترض أنه لو أمكنني فعليًا منع الأشخاص من وضع قوالب StylePtr خارج النص المُهيأ مسبقًا، لاضطر الناس إلى فعل الشيء الصحيح، لكن كيف أفعل ذلك؟ (أيضًا، يبدو هذا الحل قاسيًا جدًا، إذ قد يمنع أيضًا طرقًا صحيحة تمامًا لمناقشة قوالب StylePtr.)
حلي الحالي لربط قوالب StylePtr باستخدام linkify لا يعمل أيضًا على النص المُهيأ مسبقًا لأن بنية DOM مختلفة جدًا، لكن هذه مشكلة ثانوية يمكنني على الأرجح حلها بقليل من البرمجة.
ربما. أعتقد أنني سأستخدم هذا النمط لإضافة علامات الاقتباس الخلفية تلقائيًا إذا لم تكن موجودة، ثم استخدام استدعاء عائد بعد طهي المنشور للربط. ما لم أكن مخطئًا، لا توجد طريقة أخرى لإضافة رابط في وسط نص مُهيأ مسبقًا.
إن تشجيع المستخدمين على استخدام علامات التنصيص العكسية للكود المضمن واستخدام ثلاث علامات للتنصيص العكسية لكتل الكود هو الحل الأفضل. ربما يمكنك إنشاء موضوع مثبت حول ذلك في منتداك؟
يبدو أن مكون سمة كاشف الكود غير المنسق واعد.
ثم عليّ فقط إنشاء مكون سمة يتعامل مع الروابط داخل الكود المنسق مسبقًا، وهو ما كنت أخطط للقيام به على أي حال. سأجرب هذا بالتأكيد.
اتضح أن كل ما كان علي فعله هو تمكين دعم التعبيرات النمطية متعددة الأسطر في وحدة linkify لجعلها تعمل بالطريقة التي أرغب فيها. لذا أعتقد أنني بخير، بافتراض أن الناس يولون انتباهًا لكاشف الكود غير المنسق.