Clarify installation messages

[ojroques]

Clarify installation messages

[savq]

You're right. install foo actually prints after foo is installed, and you're also right in thinking that's confusing.

I've thought about this a little, and I think that having a buffer or a floating window with the installation info. makes sense. Updates rarely fail, but when they do it's super important to know which one failed.

Note: I'm on finals, so this might take a while :P

---

Implementation notes:

• The user should be able to choose whether the buffer opens automatically, or only on failure. Maybe add a setup function?
• Read :h api-buffer
• See whether the buffer and process counter have to be locked
• Have a table of message strings, and interpolate the repo name when necessary (this can also reduce the number of strings already hardcoded)

[savq]

Update:

Showing the number of packages currently downloaded/updated, and phrasing the prompt messages in the past tense is already in dev.

No-ops count as a success; uninstalls or hooks aren't counted, since there's no way to know a priori how many will run.

Aditionally, I've settled on not adding a floating window. Instead, Paq will write failures to a log file. The log has several advantages: It's persistent and optional, a user can look at it at whatever time, or not at all; it's also more in line with how other Lua functionality works (both the lsp and treesitter have their own log files).

[ojroques]

That would be great indeed.

[Furkanzmc]

Will there be a way to automatically open the log file when the update finishes? I find it very useful to see the commit log after an update, would it be a lot of work to include that in the logs? Or would it even make sense to include it in the logs?

[savq]

Will there be a way to automatically open the log file when the update finishes?

Having a configuration option to do that shoundn't be much trouble.

...see the commit log after an update...

My first instinct would be not to add that, since Paq updates things out of order, the log file could become quite a mess. Having separate functionalities to display the log of a single repo might make more sense, but for now it feels a bit out of scope. We can revisit the idea later.