[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57367: [PATCH] Speed up em-smart
From: |
Morgan Smith |
Subject: |
bug#57367: [PATCH] Speed up em-smart |
Date: |
Mon, 05 Sep 2022 17:48:09 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Hello,
Jim Porter <jporterbugs@gmail.com> writes:
> ;; @ While output is being generated from a command, the window will
> ;; be constantly reconfigured (until it would otherwise make no
> ;; difference) in order to always show you the most output from the
> ;; command possible. This happens if you change window sizes,
> ;; scroll, etc.
Yep the window is constantly reconfigured and that remains true even
with all the stuff I removed. I only removed stuff which forced a
redisplay. From what I can tell, we don't need to force redisplays as
everything shows up just fine. If I did my job correctly (which I
didn't, see below) then there is zero change to the logic and user
experience.
That being said I have discovered one bug in my patch. I use this
little tid bit to determine if I should scroll or not in the
eshell-output-filter-functions hook.
"(when (eq (window-buffer (selected-window)) (current-buffer)) <logic here>)"
Whereas the previous code used this logic in a few hooks:
(walk-windows
(lambda (wind)
(with-current-buffer (window-buffer wind)
(if eshell-mode
<logic here>)))
0 frame)
My code prevents the hook from being run on buffers that aren't the
eshell buffer (no clue how but it does) but it doesn't allow the hook to
run if the window isn't selected. The old code seems very complicated
though and will scroll all eshell buffers.
Is there a good way to ensure a hook is performed only on the buffer
that it was installed to?
Thanks,
Morgan
- bug#57367: [PATCH] Speed up em-smart, Lars Ingebrigtsen, 2022/09/04
- bug#57367: [PATCH] Speed up em-smart, Jim Porter, 2022/09/05
- bug#57367: [PATCH] Speed up em-smart,
Morgan Smith <=
- bug#57367: [PATCH] Speed up em-smart, Lars Ingebrigtsen, 2022/09/05
- Message not available
- bug#57367: [PATCH] Speed up em-smart, Lars Ingebrigtsen, 2022/09/06
- bug#57367: [PATCH V2] Speed up em-smart, Morgan Smith, 2022/09/06
- bug#57367: [PATCH V2] Speed up em-smart, Lars Ingebrigtsen, 2022/09/07
- bug#57367: [PATCH V2] Speed up em-smart, Jim Porter, 2022/09/09