-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Janitor #134
Conversation
Runs at idle, and currently does two things: - Closes buffers if needed and allowed - Tries to free used memory
The auto-closing buffers worries me a bit, since I will sometimes work on projects with well over 40 buffers open. Then again, is there really anyone who leaves their text editor/IDE open for over 4 hours? |
@kirbyfan64 As do we all I guess, but the question is more that of how many open buffers would you like to have open at the same time? And if you haven't viewed the buffer in I actually run the same instance until I have a need to restart it, since I just suspend the laptop. Regardless of whether you close it or not, the session handling will restore your previous list of open buffers the next time you start it (unless you start it with command line arguments), so the buffer list will grow with time unless you prune it. This will depend on your work flow I suppose, but I just open it, and thus get the list of buffers I had previously open and typically add to that while working. If you don't, and don't have it open more than 4 hours, than this would not affect you :) |
Well, I pretty much always use Howl from the command-line, so that's probably why. I guess the 4 hour limit makes sense, then. I would like it if it said which buffers in particular were closed instead of just the count. |
I generally leave Howl running for days, at least on my workstation. I like the idea of auto closing old buffers but I wonder why only do it when idle? Should we we always clean up buffers whenever a new one is opened? Also 4 hours seems a bit short - this means something I looked at in the morning may be gone by the afternoon. So 24 hours seems more reasonable to me. |
Also switch the unit of the configuration variable to be hours.
I've updated the default limit to be 24 hours, and I also changed the unit of the configuration var to be hours. No, this needn't only be done on idle, doing it upon open is also something I've considered (and that now requires one extra line). However, I wanted to make sure this is exercised properly first to find any problems with the idle clean-up. Another reason for preferring it on idle is that you won't see the feedback that buffers have been closed if done on open, as that will log success on its own. @kirbyfan64 Showing the names of the buffers closed could possibly be done if the number is small enough, but the numbers of closed buffers could easily be large enough that it won't be feasible. It could display something like "Closed 'foo.moon', 'zed.moon' (+12 others)." |
Also, how about the default of 40 for open buffers, good or bad? |
The limit of 40 seems reasonable to me. The way I work is I rarely remember if I have a buffer open unless it's in the last 5-10 that I worked with so I just try to search the buffer list. If that fails I find and open the file - I was thinking However thinking about this more I feel why should I even have to worry about whether the file is open? Why have to first guess if it's open, then try one of two commands, and if that fails try the other? Ideally I'd use one command to search a list of buffers+files and if it wasn't open it should just open it. This could be done by changing the |
Back to this PR, another things that came to mind was what would happen if a buffer was closed while the buffer list was showing? |
@shalabhc Good point, as of the last commit it now won't touch buffers if the command line is active. |
This adds a new module,
janitor
. As the name implies, it's job is to perform some cleaning, which it does automatically in the background when idle.It currently does two things:
Controlled by two new configuration variables that control how many buffers to keep open and for how long a buffer should have gone without viewing it before closing it. What values to choose for the defaults here are, as always, interesting.
It does garbage collection, and if on Linux we force the greedy malloc to release more memory back to the OS.