Re: Deffering redisplay in COMINT

[Michael Mauger <mmaug@yahoo.com>]

> 

>>  The pre hook only activates if the mode is enabled and truncate-lines
>>  is set.  When active, it disables auto-hscroll-mode.  It then appends 
>>  the output text to a temporary buffer and then returns a window's
>>  width worth of characters of each line in the temp buffer to 
>>  be written to the output buffer.  The output appears to fill each 
>>  line without the display slowdown due to long displayed lines.
>>  And because hscroll is turned off, the text merely flows up the
>>  screen quickly.
> 
> Have you tried the (presumably) simpler approach of only inserting the
> text one line at a time, i.e. accumulate the output in some undisplayed
> "buffer area" (can be a buffer, a string, or a list of strings, this
> last choice being probably the most efficient) until you see a \n and
> then insert that text (upto and including the \n, so the cursor stays in
> column 0 and doesn't risk triggering auto-hscroll-mode) while keeping
> the rest in the "buffer area"?
> 
> 
>         Stefan
> 

I hate that after beating my head against the wall for a month, you can
say "Have you tried..." and I'm sitting here going "Duh!".  ;-)  Thanks.

You are correct that by only passing along the incoming text thru 
(and including) the last newline of the preoutput text does reduce the 
auto-hscroll-mode related flickering.  The trick is detecting the prompt
at the end of the output to force the filter to flush everything.  The 
implementation is very straightforward just using a string to hold
what is left over from the prior iteration.  

Comparing the results to not having the filter, is dramatic.  I have a 
query that produces about 200 rows of data x 8000 characters per 
row (the database columns are waaaay too long for the data present, 
but that's what I have to live with).  Without the filter and 
auto-hscroll-mode engaged, the results take nearly 30 seconds to 
complete under Emacs.  (It is nearly instantaneous outside of Emacs.)  
With the filter you suggest, the results take about 8-10 seconds with 
a noticeable stutter between each row.  With the solution I had 
developed (buffering the long lines in a buffer and restoring them at 
the end of output), the results scroll by quickly in about 2-3 seconds, 
but then it hesitates at the end (as it restores the long lines in the 
buffer), for another 2-3 seconds.  So just reducing the horizontal 
scrolling is giving us the big payback and the more complex 
gymnastics is probably not worth code cost.

Thank you again, Stefan.  Thanks for the suggestion and clarifying my
thinking about how process output and display is handled in Emacs.  
Your leadership and patience is appreciated.  

I'll be adding this filtering to an existing output filter in sql.el.  

-- Michael