Doom-emacs: [BUG] التمرير البطيء / حركة المؤشر على macOS مع نافذة كبيرة

ربما نسخة مكررة من # 1301.

هذه مشكلة عامة وشائعة في Emacs و MacOS ، للأسف: https://www.reddit.com/r/emacs/comments/d2n2wh/emacs_is_slow_on_macos/. كلاهما عرضة لإعادة عرض البطء مثل هذا.

يمكنك محاولة تعطيل أرقام الأسطر باستخدام (setq display-line-numbers-type nil) والتبديل إلى نموذجنا الخفيف (ولكن تغيير modeline إلى (modeline +light) في ~/.doom.d/init.el ).

ربما قد يساعد هذا أيضًا:

(add-to-list 'default-frame-alist '(inhibit-double-buffering . t))

جرب أيضًا خطًا آخر. يبدو أن Emacs يختلف مع بعض الخطوط. Fira Code المعروف أن

إذا لم يساعد أي من ذلك ، فقد يكون الأمر بعيدًا عني أو من Doom لإصلاحه. Emacs ، للأسف ، عرضة لبطء التمرير ، وأكثر من ذلك على نظام MacOS منه على Linux.

كل هؤلاء يساعدون ، على ما يبدو. يعزز Fira Code أيضًا أداء التمرير بشكل كبير ، وهو ما أجده مزعجًا للغاية (أحب Pragmata Pro!).

لا يزال أبطأ بكثير عند تكبيره مقارنة بالنافذة الصغيرة (أو في الواقع أي محرر / IDE آخر لدي على جهازي مثل Neovim أو VS Code أو IntelliJ IDEs) ، مما يجعل emacs لا يزال مزعجًا للغاية. بعد المزيد من القراءة ، يبدو أن العرض على macOS هو ببساطة مواطن من الدرجة الثانية بالنسبة لأجهزة emac. المرجع: https://www.reddit.com/r/emacs/comments/del1yl/emacs_high_gpu_usage_on_mac/

لقد جربت Ubuntu VM من أجل المتعة فقط ، لكن أداء VMware Fusion بدقة شبكية العين يبدو أنه يمتص كثيرًا لمقارنة أي شيء.

جرب أيضًا خطًا آخر. يبدو أن Emacs يختلف مع بعض الخطوط. Fira Code المعروف أن

هل توجد قائمة بالخطوط المعروفة بأنها تعمل بشكل جيد مع Emacs؟ أنا أستخدم Iosevka وأواجه مشكلات مماثلة مع سرعة التمرير / الحركة في نظام macOS.

تحرير: تم تثبيت Emacs كـ brew install emacs-mac --with-modules --with-rsvg --with-natural-title-bar .

لدي نفس المشكلة بالضبط. يعمل إعداد macos الخاص بي تمامًا مثل فيديو OPs.

لمعلوماتك ، display-line-numbers-type و inhibit-double-buffering لم تفعل الكثير بالنسبة لي. أدى تغيير الخط إلى "موناكو" إلى الحيلة. مثل OP ، لا يزال ليس "سلسًا بالزبد" ولكن الآن على الأقل أحصل على نفس أداء التمرير مثل spacemacs.

zyeri أنا أيضًا أستخدم Iosevka مع emacs-plus ولدي نفس المشكلة ، على سبيل المثال في تمرير spacemacs كان سلسًا ، ربما لديهم بعض الحلول.

testarossaaaaa نعم يبدو أن spacemacs لا تعاني من هذا على الرغم من كونها تعتمد على emacs أيضًا ... لقد استمتعت بالعذاب كثيرًا وبالنسبة لي هذا هو الشيء الوحيد الذي يمنعني من إجراء التبديل :(

إذا كان أي شخص يعرف نوعًا من الحل البديل ، فسأكون ممتنًا للغاية!

أحد الاختلافات التي لاحظتها بين spacemacs و dom-emacs هو قيمة scroll-conservatively :

• في الفضاءات ، scroll-conservatively = 101
• في dom-emacs ، scroll-conservatively = 10

ربما يمكنك تجربة (setq scroll-conservatively 101) ومعرفة ما إذا كان ذلك مفيدًا؟

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

لما يستحق ، يمكنني إعادة إنتاج هذا على Emacs HEAD بتكوين _ no_. لا أعتقد أن الأمر يتعلق بـ Doom ، لكنني سأحاول استخدام Spacemacs والإبلاغ. ربما يفعلون شيئًا لإصلاحه عن طريق الخطأ؟ (في الوقت الحالي ، أعود إلى فرع Emacs 27 ، والذي لا أعتقد أن به هذه المشكلة.)

ربما نسخة مكررة من # 1301.

هذه مشكلة عامة وشائعة في Emacs و MacOS ، للأسف: https://www.reddit.com/r/emacs/comments/d2n2wh/emacs_is_slow_on_macos/. كلاهما عرضة لإعادة عرض البطء مثل هذا.

يمكنك محاولة تعطيل أرقام الأسطر باستخدام (setq display-line-numbers-type nil) والتبديل إلى نموذجنا الخفيف (ولكن تغيير modeline إلى (modeline +light) في ~/.doom.d/init.el ).

ربما قد يساعد هذا أيضًا:

(add-to-list 'default-frame-alist '(inhibit-double-buffering . t))

جرب أيضًا خطًا آخر. يبدو أن Emacs يختلف مع بعض الخطوط. Fira Code المعروف أن

إذا لم يساعد أي من ذلك ، فقد يكون الأمر بعيدًا عني أو من Doom لإصلاحه. Emacs ، للأسف ، عرضة لبطء التمرير ، وأكثر من ذلك على نظام MacOS منه على Linux.

أواجه نفس المشكلة مثل OP ، فقد ساعدني تعيين (setq display-line-numbers-type nil) - التأخر أقل بكثير الآن.

(modeline +light) مع (setq display-line-numbers-type t) له تأثير ضئيل على جهازي. (add-to-list 'default-frame-alist '(inhibit-double-buffering . t)) لم يفعل الكثير أيضًا.

أنا أستخدم 26.3 brew tap railwaycat/emacsmacport وحجم Iosevka: 13 من brew tap homebrew/cask-fonts

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

الإعداد الخاص بي هو:

• brew install emacs-plus --without-spacemacs-icon --HEAD --with-emacs-27-branch --with-jansson --with-xwidgets
• الموت المواضيع
• خط مينلو

لقد جربت تركيبات مختلفة لإبرازها وإليك النتائج التي توصلت إليها:

شيء سريع لإصلاحه هو hl-line . عندما يتم تمكين ذلك ، يتحرك المؤشر ببطء. لقد قمت بحلها باستخدام hl-line+ حيث يمكنني تكوين التمييز فقط عند التباطؤ ، لذلك لن يؤدي تحريك المؤشر إلى إبراز الخط الحالي ، وبالتالي لا يوجد الكثير من إعادة الرسم على ما أعتقد. التكوين الخاص بي على النحو التالي:

(use-package hl-line+
  :load-path "3rd" # or wherever you put hl-line+.el
  :config
  (hl-line-when-idle-interval 0.3)
  (toggle-hl-line-when-idle 1))

مشكلتي الكبرى هي تمكين كل من أدلة تمييز المسافة البادئة display-line-numbers وعلامة تمييز المسافة البادئة في نفس الوقت ، أثناء استخدام unicode char \x2502 الافتراضي كحرف إرشادي.

إذا قمت بتعطيل أي من هذين ، فسيكون أكثر استجابة ؛ إذا كنت أستخدم يونيكودًا مختلفًا ولكن متشابهًا ( \xFFE8 في حالتي ، إنه متقطع قليلاً للأسف) ، يمكنني الحفاظ على كلاهما ممكّنًا أثناء الاستجابة الجيدة.

بشكل عام ، هذا هو التكوين الخاص بي:

(use-package doom-themes
  :ensure t
  :init
  ;; Global settings (defaults)
  (setq doom-themes-enable-bold t    ; if nil, bold is universally disabled
        doom-themes-enable-italic t) ; if nil, italics is universally disabled
  :config
  (load-theme 'doom-one t)

  ;; Enable flashing mode-line on errors
  (doom-themes-visual-bell-config)

  (use-package doom-themes-ext-treemacs
    :init
    (setq doom-themes-treemacs-theme "doom-colors")) ; use the colorful treemacs theme)
  (doom-themes-treemacs-config)

  ;; Corrects (and improves) org-mode's native fontification.
  (doom-themes-org-config))

(use-package hl-line+
  :load-path "3rd"
  :config
  (hl-line-when-idle-interval 0.3)
  (toggle-hl-line-when-idle 1))

(use-package display-line-numbers
  :ensure nil
  :init
  (setq display-line-numbers-width-start t)
  (global-display-line-numbers-mode))

(use-package highlight-indent-guides
  :ensure t
  :delight highlight-indent-guides-mode
  :init
  (setq highlight-indent-guides-method 'character
        ;; default is \x2502 but it is very slow on Mac
        highlight-indent-guides-character ?\xFFE8
        highlight-indent-guides-responsive 'top))

باستخدام emacs المترجمة محليًا 27.0.91 ، تكون سرعة التمرير جيدة جدًا.

خطوات ما فعلته:

git clone https://github.com/emacs-mirror/emacs.git
cd emacs
git checkout emacs-27.0.91
./configure
# if configure works then run
make install

الغريب أن الإصدار> 28 من emacs كان يعاني من نفس مشكلة التمرير البطيء.

قررت أن أعطي العذاب فرصة أخرى ، وما زلت أواجه مشكلات.

حاولت مرة أخرى مع emacs-27 وما زالت المشكلة ظاهرة. لا يزال تبديل الخط "موناكو" هو الشيء الأكثر فعالية.

يساعد أيضًا تعيين "أرقام خطوط العرض" على قيمة خالية قليلاً ، ولكن ليس كثيرًا.

honnix هل يمكنك تقديم المزيد من التفاصيل حول ما عليك القيام به لتهيئة hl-line +؟ لكوني جديدًا إلى حد ما على Doom ، ما زلت غير متأكد من مكان وضع مقتطفك. لم يقم أي من الحزم .el ولا config.el بالخدعة بالنسبة لي.

آسف لأنك ما زلت تواجه المشكلة. عملت emacs-27 من أجلي بمجرد أن جمعت التطبيق بأكمله محليًا لمعلوماتك.

إحدى الطرق الممكنة لتتبع مصدر البطء هي عبر explain-pause-mode عند بدء التشغيل https://github.com/lastquestion/explain-pause-mode ، يمكنه تقديم رؤى حول موارد الخنازير.

أنا أيضا لدي التمرير البطيء على شبكية العين MacBook مع emacs 28. تكوين Spacemacs على نفس مخطوطات emacs بشكل جيد. لقد قمت بالتبديل إلى نفس الخط والحجم في تكوين Spacemacs الخاص بي وهو يساعد قليلاً ولكن ليس كثيرًا. يبدو أن عرض أرقام الأسطر هو أكبر مذنب وهو أمر محترم تمامًا مع إيقاف تشغيله. لدهشتي ، يتم تمرير Spacemacs بشكل أسرع بكثير مع تشغيل أرقام الأسطر. بقدر ما أستطيع أن أقول أنه يستخدم نفس display-line-numbers-mode . الإعداد على نسبي أو عادي لا فرق.

لقد حاولت التنميط واستخدام explain-pause-mode ولكن لا يبدو أن هناك أي شيء واضح في التقارير.

أنا أستخدم واجهات المستخدم الرسومية emacs وإذا جعلت النافذة صغيرة ، فسيتم تمريرها جيدًا.

أشعر وكأنني منتقي nit لكنني أقضي الكثير من الوقت في محرر وأكون قادرًا على التمرير بسلاسة وسرعة على الرغم من أن النص يحدث فرقًا في مدى متعة استخدام المحرر.

أنا أعمق قليلاً لأعرف أين أتطلع إلى تحسينه ، لقد حاولت البحث من خلال كود spacemacs للتمرير وأرقام الأسطر لمعرفة ما إذا قاموا بتطبيق أي شيء محدد والشيء الوحيد الذي وجدته هو (setq scroll-conservatively 101) الذي لم يحدث فرقًا بالنسبة لي.

maxwedwards راجع https://github.com/hlissner/doom-emacs/blob/develop/docs/faq.org#why -is -scrolling-slow-in-emacsdoom وجرب ما تقترحه.

شكراhlissner. لقد قمت بالاطلاع على هذه القائمة وأرقام الأسطر تحدث فرقًا كبيرًا ولكن الشيء الأكبر إلى حد بعيد هو ببساطة سحب النافذة أصغر. لا أعرف ما الذي تفعله Spacemacs ، لكن هذا شيء يتم عرضه على شاشات شبكية MacOS باستخدام emacs. لقد شعرت بخيبة أمل من روابط emacs reddit المنشورة أعلاه والتي أشار إليها المشرفون على أنها مشكلة MacOS وليست مشكلة Emacs ، ويبدو أنهم لا يعترفون حتى بأنها مشكلة.

يؤدي تغيير الخط وجعل الخط أكبر إلى تسريع خطه بنسبة تقل عن 10٪.

أغرب شيء هو أن الفضاءات تصبح أسرع مع تشغيل أرقام الخطوط! شيء غريب يجري.

شكرا لعملك على Doom.

أقوم بتشغيل Emacs 27 على جهاز Macbook Pro بشاشة خارجية بدقة 4K. بالنسبة لي ، فإن مجرد التبديل من وضع hl-line الافتراضي إلى hl-line + والتكوين الخامل أحدث فرقًا كبيرًا والتمرير الآن مقبول جدًا. أود أيضًا الاحتفاظ بأرقام الأسطر (عادة قديمة أفترض).

ولكن أنا أيضا مثلhlissner الصورة المشورة للتنقل في أكثر بطريقة "الشر":

لا تهرس j (أو Cn) للتمرير. يمكن للمستخدمين الأشرار التمرير لمسافات طويلة باستخدام Cd و Cu ، على سبيل المثال ، لتجنب هذا البطء. بخلاف ذلك ، استخدم آليات البحث للتنقل ، مثل isearch (Cs) أو البحث الشرير (/).

لقد حصلت بالفعل على تحسن كبير بعد الترقية إلى Emacs 27 عبر التمرير emacs-plus يبدو سريعًا مثل vim الآن هذا مع hl-line + set. لقد أجريت إعادة تثبيت كاملة كجزء من الترقية ، فربما يكون ذلك مفيدًا؟

كان لدي تعقيد آخر كما وصفته هنا https://github.com/jwiegley/use-package/issues/835 ، الإصلاح الذي منحني أيضًا دفعة كبيرة ويمكنني العودة إلى خط hl.

jonasagx لست متأكدًا مما إذا كنت قد اكتشفت كيفية تكوين hl-line +.

هذا ما فعلته. لقد قمت بتنزيل hl-line + .el وقمت بوضعه على .emacs.d/3rd ، ولدي ما يلي في .emacs.d/init.el .

(use-package hl-line+
  :load-path "3rd"
  :config
  (hl-line-when-idle-interval 0.3)
  (toggle-hl-line-when-idle 1))

بالنسبة لي ، أدى تغيير الخط (Jetbrains Mono -> Fira Code) إلى إصلاح المشكلة.

هل يعرف أي شخص ما هو معنى بعض الخطوط التي تجعلها تعمل بشكل أفضل؟ ربما يتعلق الأمر بتخطيط يونيكود والحجم؟

يمكن تأكيد hl-line + mod إلى جانب تعطيل أرقام الأسطر التي أحدثت فرقًا كبيرًا. أنا أستخدم شاشات 1440p مع Mac. سرعة التمرير تقريبًا بنفس سرعة vim. أنا في Emacs 26.

أضفت حزمة الاستخدام إلى ملف config.el المخصص في المجلد /user/.doom.d

بالنسبة لي ، أدى تغيير الخط (Jetbrains Mono -> Fira Code) إلى إصلاح المشكلة.

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

يمكن تأكيد hl-line + mod إلى جانب تعطيل أرقام الأسطر التي أحدثت فرقًا كبيرًا. أنا أستخدم شاشات 1440p مع Mac. سرعة التمرير تقريبًا بنفس سرعة vim. أنا في Emacs 26.

أضفت حزمة الاستخدام إلى ملف config.el المخصص في المجلد /user/.doom.d

هذه ثابتة بالنسبة لي!!

مستخدم Linux قادم من neovim للتحقق من Doom Emacs حيث سمعت أشياء جيدة ، ويبدو أنه مشروع رائع :) سأغوص بالتأكيد في عالم emacs بشكل أعمق.

تنطبق مشكلة التمرير بالنسبة لي أيضًا وهي محيرة. يقوم j (Ce) بالتمرير لأسفل ببطء (بسلاسة) ، بينما يتم تمرير k (Cy) بسلاسة (ببطء). لست متأكدًا مما هو مختلف حقًا تحته. يمكن إصلاح المشكلة تمامًا بإيقاف تشغيل ترقيم الأسطر النسبي (الأشياء الأخرى المذكورة هنا لا تعمل) ، على الرغم من أنني أخشى أن يكون هذا أمرًا باهظًا للغاية بالنسبة لي. ربما يساعد التمرير باستخدام j & Ce الأشخاص الذين يأتون إلى هنا لأنني لم أر هذا التجاوز المنشور بعد في أي مكان (في حال كان يعمل مع الآخرين).

تحرير: للإضافة إلى ذلك ، عند تشغيل Doom Emacs في Alacritty ، يبدو أن العرض المتسارع للأجهزة يخفف أيضًا من مشكلة التمرير ، على الرغم من أنه لا يعالجها بالكامل.