Notify user if dot, their personal config, or their packages are out of date

[cg505]

This has been floating around my head for a while, and since we've been throwing a bunch of shit on the board lately, I thought I might as well get it out there.

The idea is basically that after we start we spin off a few processes that check to see if

1. any emacs packages need updating
2. dot is out of date
3. the loaded user config is out of date

If any of these are true, insert the results in a comment in *scratch*.

Thoughts @rye @samontea?

Task List:

• [x] #66 Updating kotct/packup UI
• [ ] Creating kotct/dotup a dot function for updating dot configs with the UI from #66
• [ ] Creation of a unified update function kotct/up for both packages and dot configurations

[samontea]

i think if we expand to zsh configs we're going to have to change how we notify, but i like this idea. we should model it after how oh-my-zsh does it. (ever n days where n is a natural number that is set somewhere in the config)

[cg505]

Why not just check every time emacs starts, since there's no overhead?

[rye]

I agree with this, we should definitely run a warning at startup. Don't do this every n days. I'm hearing talk in Slack about doing this in *scratch* at startup but I don't think this is the best option because Git requests can take a while.

[samontea]

I think that we should open up a new buffer *kotct/updates* w/ prompts to update each individual thing that's in need of updating or all thing that need updating.

[rye]

Yeah, I agree with @samontea. Either that or use messages. We could build a system to help with the updating process, too.

[samontea]

The UI envision would look like this

update all
- update all emacs packages
  - package 1 -> 2
  - ...
- update dot
  - 198243 -> 81324
- update samontea config
  - 198349 -> 981324

[cg505]

That looks sweet. We should have a global variable that you can use to disable the update window taking focus. I also don't think the kotct/ prefix is necessary in the buffer name but it doesn't matter much.

[rye]

So we'll either pop up a buffer window for @samontea's updating interface or just display a message. (If the user decided to suppress the update window, that is.) Would this then replace packup as well? (i.e. assume the responsibility of updating packages as well?)

[samontea]

@cg505 ideally kotct/update-check is a function you can also call, and I want a buffer i know i can overwrite and update w/o loosing someone else's work. i think the prefix is the only way we can ensure that.

[cg505]

@rye We should definitely leave packup in case users want to do manual updates. Also important to note that I'm not saying we shouldn't create the buffer if you set whatever var. The buffer is created, it just doesn't take focus.

[rye]

Yeah, @samontea you could make kotct/update-check a command/defun and then have that use something like *kotct/updates* as a buffer name just to be safe.

Also, @cg505, yeah let's leave packup in place but I like the ability to update packages in this UI as well.

[cg505]

@samontea I think it would be a pretty wild scenario if you had a buffer called *updates* open, but I understand your reasoning and I think your decision is fine.

[rye]

If/when we add a ZSH configuration, I still think the update checking should be independent.

[cg505]

I don't think so but I also don't think this issue is the place for discussion.

[rye]

Okay. Well, this should be done one way or the other.

[rye]

Another good idea for this issue that I just had when I looked at my ELPA folder was that we should really add a system for cleaning up packages and deleting older ones. I'm not sure if Emacs does this currently, but if there are packages that are no longer needed or have been superseded by a new version, they should be moved.

[cg505]

There's not a way to do this that I know of without doing it manually through package-list.