[dev] [st] [PATCH] Remove expose() to prevent unresponsiveness

--- Doc, it hurts when I do this: - have a huge st (say, 100 x 200 rows x cols?) - take a floating window and gently wave it over st for a second or two, generating lots of Expose events - switch to st and try to type - wait for 20+ seconds for all the damn redraw()s to finish - see

Re: [dev] [st] Larger HISTSIZE consumes huge memory

> Wrong: ... Sorry for posting again. Does that mean If I have single st window open it'll allocate 120MiB but won't actually use that?? And also other applications can't use that space ?? With 10 st window you have 1GiB less, available space for other applications ?

Re: [dev] [st] Larger HISTSIZE consumes huge memory

> Wrong: ... Thanks. If that's the case then topic closed.

Re: [dev] [st] Larger HISTSIZE consumes huge memory

> Also, why do you want 4 lines of backlog? to look at your stacktraces On 6/22/17, Eric Pruitt wrote: > On Wed, Jun 21, 2017 at 07:39:07PM +0600, Techno Implant wrote: >> So my question is if there's a patch that can make st handle >> scrollback lines dynamically

Re: [dev] [st] Larger HISTSIZE consumes huge memory

On Wed, Jun 21, 2017 at 07:39:07PM +0600, Techno Implant wrote: > So my question is if there's a patch that can make st handle > scrollback lines dynamically rather than preallocate. > > And also will there be any daemon mode available for st? You could use tmux. It dynamically allocates memory

Re: [dev] [st] Larger HISTSIZE consumes huge memory

* Techno Implant [2017-06-22 19:38]: > > What's the problem here? It's only virtual memory, so the Kernel should > > do exactly that already. > > ps aux for st and urxvt > > rss is ram memory from my understanding . 100MB or larger for a > terminal is much. Wrong:

Re: [dev] [st] Larger HISTSIZE consumes huge memory

> What's the problem here? It's only virtual memory, so the Kernel should > do exactly that already. ps aux for st and urxvt burhan7634 0.1 0.3 181100 20748 ?S19:24 0:00 urxvt burhan7650 0.1 0.3 181092 20296 ?S19:24 0:00 urxvt burhan7664 0.1 0.3

Re: [dev] [st] Larger HISTSIZE consumes huge memory

silvan is correct, urxvtd crashed once and wasted my time. once is already too much to warrant the minuscule benefit. urxvt still uses less memory than st, putting any effort to minimize it further is a waste of time.

Re: [dev] [st] Larger HISTSIZE consumes huge memory

* Techno Implant [2017-06-21 19:39]: > With HISTSIZE being 2000 memory consumed is around 8MiB > And for 4 it's 120MiB. This is a large number for terminal. > Whereas for urxvt I set saveLines to 65000 and it consumes less around > 8MiB. It increases when I have more

Re: [dev] [st] Larger HISTSIZE consumes huge memory

On Thu, Jun 22, 2017 at 9:05 AM, Ivan Tham wrote: > I find urxvtd and find it very useful when using a bunch or terminals > since it uses far less memory than st when there are 6 terminals opened. One issue with the daemon approach is that when the daemon dies, all the

Re: [dev] [st] Larger HISTSIZE consumes huge memory

I find urxvtd and find it very useful when using a bunch or terminals since it uses far less memory than st when there are 6 terminals opened. Just run `urxvtd -q -o -f` on startup and after that just run urxvtc and subsequent terminal startup. On Wed, Jun 21, 2017 at 11:00:22PM +0600, Techno