GNU bug report logs - #57367
[PATCH] Speed up em-smart

Previous Next

Package: emacs;

Reported by: Morgan Smith <Morgan.J.Smith <at> outlook.com>

Date: Tue, 23 Aug 2022 20:07:02 UTC

Severity: normal

Tags: moreinfo, patch

Fixed in version 30.1

Done: Jim Porter <jporterbugs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #31 received at 57367 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Morgan Smith <Morgan.J.Smith <at> outlook.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 57367 <at> debbugs.gnu.org
Subject: Re: bug#57367: [PATCH V2] Speed up em-smart
Date: Thu, 8 Sep 2022 21:36:17 -0700
On 9/6/2022 6:30 PM, Morgan Smith wrote:
> I've attached my patch V2.
> 
> This restores some more of the original logic that I have now realized
> was indeed necessary.  Again, this patch should not actually change
> anything with respect to program logic, flow, or user experience.  In my
> limited testing, it seems to act just as it did before (but
> significantly more performant).

Thanks, this does indeed seem a lot faster. I do notice one small change 
in behavior though: after starting Eshell with the em-smart module 
loaded, run "echo hi" and then split the window vertically with 'C-x 2'. 
Before the patch, the window doesn't scroll. After the patch, the window 
is scrolled so that the "echo hi" block is at the top (i.e. the "Welcome 
to the Emacs shell" banner is hidden).

The same sort of thing happens if you run a command with a lot of output 
first and then run "echo hi". Before splitting, the "echo hi" block is 
at the bottom. Without this patch, 'C-x 2' maintains that position (i.e. 
it scrolls the minimum amount of the previous command out of view so 
that you can see the most-recent command). With the patch, 'C-x 2' 
scrolls *all* of the previous command out of view, so the "echo hi" 
block is at the top.

I think the pre-patch behavior is the most-usable: if you can fit all of 
the last command in the window, it should be at the bottom so that you 
can see (some of) the previous command.

(I also saw some strange issue with resizing the windows via the mouse, 
but I can't reproduce it anymore. If I can figure out how trigger this 
reliably, I'll send an update. Sorry that's not very helpful at present...)




This bug report was last modified 1 year and 211 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.