Skip to content
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

Merged
merged 6 commits into from
Nov 23, 2015
Merged

Janitor #134

merged 6 commits into from
Nov 23, 2015

Conversation

nilnor
Copy link
Contributor

@nilnor nilnor commented Nov 19, 2015

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:

  • Automatically closes old buffers

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.

  • Releases memory

It does garbage collection, and if on Linux we force the greedy malloc to release more memory back to the OS.

Runs at idle, and currently does two things:

- Closes buffers if needed and allowed
- Tries to free used memory
@refi64
Copy link
Contributor

refi64 commented Nov 19, 2015

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?

@nilnor
Copy link
Contributor Author

nilnor commented Nov 19, 2015

@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 X minutes, do you want it to be closed?

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 :)

@refi64
Copy link
Contributor

refi64 commented Nov 19, 2015

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.

@shalabhc
Copy link
Contributor

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.
@nilnor
Copy link
Contributor Author

nilnor commented Nov 20, 2015

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)."

@nilnor
Copy link
Contributor Author

nilnor commented Nov 20, 2015

Also, how about the default of 40 for open buffers, good or bad?

@shalabhc
Copy link
Contributor

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 open-recent would be useful here since I wont have to navigate the folder or project, etc.

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 open-recent semantics to show recently opened files (rather than recently closed) - so it would show a mix of open and closed files, up to 1000 most recently opened. Based on what I select, it would either buffer switch or open a new file. What do you think?

@shalabhc
Copy link
Contributor

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?

@nilnor nilnor mentioned this pull request Nov 20, 2015
@nilnor
Copy link
Contributor Author

nilnor commented Nov 20, 2015

@shalabhc Good point, as of the last commit it now won't touch buffers if the command line is active.

@nilnor nilnor merged commit 59a619a into master Nov 23, 2015
@nilnor nilnor deleted the janitor branch November 23, 2015 11:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants