Re: [code] Message Buffer not auto scrolling and slowdown

From: Mitchell <m.att.foicica.com>
Date: Thu, 5 Jun 2014 08:44:59 -0400 (Eastern Daylight Time)

Ryan,

On Wed, 4 Jun 2014, Ryan Pusztai wrote:

> On Jun 4, 2014 3:02 PM, "Mitchell" <m.att.foicica.com> wrote:
>>
>> Hi Ryan,
>>
>>
>> On Tue, 3 Jun 2014, Ryan Pusztai wrote:
>>
>>> In Textadept 7.3 x86_64 on Ubuntu 14.04 x86_64, the message buffer does
> not
>>> seem to auto-scroll to the bottom anymore. I have set "ui.SILENT_PRINT =
>>> true" and am using tabs. I have split the view once and have the message
>>> buffer in one buffer and my code in the other. I am using the built-in
>>> "run" function and a Lua file and I am just watching "print()" from the
>>> script run. Does anyone else see this? I find it really hard because I
>>> usually look at that output and want the latest results to show. It does
>>> not seem to have anything to do with "ui.SILENT_PRINT = true". I run into
>>> some times where I set SILENT_PRINT to false and the tab is not selected
> as
>>> well.
>>
>>
>> Textadept only scrolls a print buffer when `ui.SILENT_PRINT` is false or
> that when print buffer is focused. Textadept has never had the ability to
> scroll print buffers in separate, split views.
>
> I thought so, but I used to use this as a separate view that is at the
> bottom and in other split views I run scripts that print messages. I would
> go days with this setup. I feel like tabs changed this behavior and the
> SILENT_PRINT is not functioning the same with tabs. I need the auto-scroll
> more that the silent print and if I just don't set any setting I still
> don't see the auto-scrolling work if you have 2 splits; 1 with a script and
> another with the message buffer. Now I thought it would focus the message
> buffer and auto scroll, but that is not what I see. It focuses the first
> time, but then I focus the script and run again until the text in the
> message buffer requires the buffer to scroll. I hope this makes sense and
> helps to reproduce the issue.

Try the latest nightly build. I think I fixed this. The spawning
functionality introduced in 7.2 silently enables `ui.SILENT_PRINT`. I've
modified the behavior slightly to ensure the message buffer is initially
focused upon running a compile, run, or build command. Leaving the focus
in that buffer enables autoscrolling.

>>> Also I am seeing a big slow down as I print to the message buffer with a
>>> few hundred lines. I press Ctrl+r and then it prints the command-line,
> then
>>> hangs till all the text output is done printing to the message buffer. I
>>> can time my script and it shows it is running full speed, but the
> printing
>>> to the message buffer is slow. So slow that for a simple script taking .5
>>> seconds to run makes the OS think Textadept is hung and changes the
> window
>>> to the not responding color. This same script runs in half a second on a
>>> plain terminal. Anyone seeing this?
>>
>>
>> Textadept's "compile", "run", and "build" commands print a single line of
> process output at a time and search that line for any warnings or errors to
> mark. That is likely causing most of the slowdown. However, even running
> "for i = 1, 100 do print(i) end" from the command entry is a bit on the
> slow side. I think that's related to Textadept performing linear search to
> find a suitable print buffer.
>
> Well maybe run the script over and over and just watch how slow it gets. I
> know this worked much better in the 7.0 release. I wonder if it has to do
> with requiring socket. I am using that in the script. Does the scripts ran
> load their requires into Textadept?
>
> I am not sure if internals changed but I print all the time to debug as I
> develop and it gets so slow (5+ seconds before any prints happen) I feel
> like I need to use the terminal instead. And I am not talking about a
> massive amount of prints either but the buffer builds up (300-500 lines)
> over runs. Can I disable the search?

I saw your follow-up e-mail and tried reproducing, but my machine doesn't
have any slowdown, at least not with the change mentioned above. I think
that fix fixed this problem. Let me know otherwise.

If you'd like to disable the search, connect to `events.COMPILE_OUTPUT`,
`events.RUN_OUTPUT`, and `events.BUILD_OUTPUT` with index 1 and call
`ui.print()`. For example:

   events.connect(events.RUN_OUTPUT, function(lexer, output)
     ui.print(output)
   end, 1)

Cheers,
Mitchell

-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Thu 05 Jun 2014 - 08:44:59 EDT

This archive was generated by hypermail 2.2.0 : Fri 06 Jun 2014 - 06:33:22 EDT