حدد فقط محتوى عنصر قائمة أو اقتباس

مرحبًا، لاحظت أنه عندما يختار المستخدم
Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-12-07%20PM) ،
يتم تحديد محتوى النص المميز فقط، مما يسمح للمستخدم بالبدء بالكتابة فورًا.
Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-16-41%20PM)

وهذا ينطبق أيضًا على النص القوي.
Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-20-24%20PM)

ومع ذلك، عندما يقرر المستخدم إنشاء قائمة مرتبة أو قائمة غير مرتبة أو اقتباس كتلي، يتم تحديد رمز لوحة المفاتيح الخاص بـ Markdown أيضًا، مما يعني أن المستخدم لا يستطيع التوقف عن الكتابة فورًا.

Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-13-38%20PM) Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-13-42%20PM) Screenshot%20of%20Google%20Chrome%20(8-1-18%2C%202-13-35%20PM)

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

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

أخيرًا، وفي إطار مساعدة الأشخاص الذين لا يعرفون Markdown، هل يمكن استبدال “النص القوي” بـ “النص العريض” واستبدال “النص المميز” بـ “النص المائل”؟

9 إعجابات

I like this suggestion, @codinghorror’s call on the wording here. I agree calling italics emphasised in the tooltip is somewhat confusing. Looking at Stack Exchange sites it uses “Emphasis” and “Strong” so there is precedent even in non tech sites. GitHub uses “Bold” and “Italic”.

Regarding making Italics/Bold smarter. There are quite a few edge cases… for example, when you highlight this block and hit “B” what do you expect?

- test
    -  text
-test
(3) test

4. test

[spoiler]
test
[/spoiler]

test [i]test
test[/i]

The ideal outcome has a LOT of magic rules, and we don’t want to have to write a full parser here.

- **test**
    -  **text**
**-test**
**(3) test**

4. **test**

[spoiler]
**test**
[/spoiler]

**test [i]test
test
[/i]**

I am sort of pr-welcome here, but we got to determine what a very simple set of rules that capture the 99% case first.

4 إعجابات

I see (1) highlighting text, then hitting “B” as different from (2) not having text and hitting “B”. The first case does have a lot of magic rules. Perhaps until there’s rich text editing (if that’s at all a priority), include a button that links to Markdown syntax? An you know, I think the second case already works very well for “B” and should be replicated for lists and blockquotes.

إنها مشكلة بسيطة، لكن هذا لا يزال يحدث مع عناصر القائمة المرتبة وغير المرتبة:

أفترض أن هناك استدعاءً لـ setSelectionRange يحتاج إلى أن تكون قيمة البداية الخاصة به مزاحة بطول بناء جملة Markdown (“*” أو “1.”) + 1 للمسافة.

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

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

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

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

من الجيد معرفة ذلك! هذا يعني أنني لم أضع يومي في إضافة أزرار تنسيق إلى محرر markdown.\n\nأيضًا، يمكنني تأكيد أن هذه هي المشكلة في شريط أدوات المؤلف:\n\n[quote="simon, post:4, topic:93672"]\nأفترض أن هناك استدعاء لـ setSelectionRange يحتاج إلى أن تكون قيمته الابتدائية مزاحة بطول بناء جملة markdown\n[/quote]\n\nأنا متأكد من أن شخصًا ما يمكنه إصلاح ذلك بسرعة، ولكن يسعدني تقديم طلب سحب (PR) إذا كان بإمكانه الانتظار لفترة أطول قليلاً.

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