Skip to content
This repository has been archived by the owner on Apr 24, 2020. It is now read-only.

Implement Use of zsh-async #331

Closed
bhilburn opened this issue Oct 26, 2016 · 8 comments
Closed

Implement Use of zsh-async #331

bhilburn opened this issue Oct 26, 2016 · 8 comments

Comments

@bhilburn
Copy link
Member

bhilburn commented Oct 26, 2016

Okay, I'd really like to get things moved over to using zsh-async, which I think will improve a number of the speed issues some users have with certain segments. I e-mailed the author of zsh-async a while back, @mafredri, and received this response:

glad you're finding use for zsh-async :)! First off, I'm perfectly fine with bundling (we do it with prompt-pure as well!). Looking at the install instructions, though, I don't see much benefit from bundling, most steps still require running command-line options, and in this case one more command would be introduced. Either way, the choice is yours.

Taking a quick peek at the code I do have some comments / feedback but don't have the time to properly reply right now, I'll have a closer look tonight or tomorrow :).

Regarding #2, I would recommend loading async with autoload:

autoload -Uz async && async

that is, after making sure it's in the users $path. This could easily be checked / added in the prompt init if bundled.

@andjscott and @Tritlo actually put in a bunch of effort into putting together a zsh-async prototype, the discussions around which can be found in closed PRs (but not merged) #262 and #263.

@andjscott - I saw you closed #263 a couple of months ago? Was that just due to inactivity?

Based on our discussions previously, one of the key decisions was whether or not to use the temp file method:

As Tritlo said, there currently isn't a choice. The choice they get, (the _ASAP variable) is to make the prompt load each element indepenently rather than as a group.

Tbh I now think that the zsh-async approach is better as it only adds async support if the user has the async library installed (progressive enhancement) and keeps the workload in zsh rather than creating temporary files. A negative is that the "ASAP" method isn't implemented.

I was previously wary of using temp files, but am more okay with it now. That said, we do need to preserve ease-of-installation of powerlevel9k, which leaves us with two routes:

  1. We bundle zsh-async with powerlevel9k and autoload it.
  2. We make zsh-async an optional dependency and make it possible for powerlevel9k to seamlessly work without it.

My preference would be the first one, because realistically I think most folks will want it.

@andjscott @Tritlo @wadkar - What are your thoughts on the best way to proceed, here?

@wadkar
Copy link
Contributor

wadkar commented Nov 18, 2016

I am thinking out loud here. The first option to bundle zsh-async would be nice for users as they will not have to do anything. Do you want me to try that out? I can switch to another PR/Branch if you want.

I am curious as to how much zsh-async changes. I would imagine it to be largely stable/mature "async" library, so we can just bundle it once and forget it.

@bhilburn
Copy link
Member Author

I agree, @wadkar. I think the best solution would be to bundle it with pl9k. It looks like zsh-async is still getting updates, but the pace isn't anything crazy. I don't think it would be a problem to bundle and then update occasionally with pl9k official releases when we wanted a newer version.

If you are up for trying it out, that would be really great. I think doing this well could significantly improve pl9k.

@wadkar
Copy link
Contributor

wadkar commented Nov 18, 2016

Sure! I have some time over the weekend. I am on the next branch usually.
Is there a PR specific pull i should be fetching?
On Fri, Nov 18, 2016 at 10:08 Ben Hilburn [email protected] wrote:

I agree, @wadkar https://github.com/wadkar. I think the best solution
would be to bundle it with pl9k. It looks like zsh-async is still getting
updates, but the pace isn't anything crazy. I don't think it would be a
problem to bundle and then update occasionally with pl9k official releases
when we wanted a newer version.

If you are up for trying it out, that would be really great. I think doing
this well could significantly improve pl9k.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#331 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwJ_6k2L2DzGNtq8hYhFYH8sJJmqk_qks5q_b9vgaJpZM4KhKp9
.

@bhilburn
Copy link
Member Author

Not right now, no. We actually don't have an active branch for this development, at the moment.

The furthest we got in the past was @andjscott's and @Tritlo's work in #263.

@dritter
Copy link
Member

dritter commented Nov 18, 2016

FYI: I am currently working on getting async into the theme. I am working on a different branch though (and don't have anything to show yet), because I wanted to try it without zsh-async first (to understand the concept, not because I dislike zsh-async)..

@Tritlo
Copy link
Contributor

Tritlo commented Nov 19, 2016

I'm still using the stuff we did in #263, and it's worked well for me so far. Some wonkyness at times, but otherwise great. I'd love to test out a zsh-async based version though.

@polarathene
Copy link

Would be great to see support for this :) I don't know about other methods for managing themes/plugins but with zplug and the pure theme to use async was as easy as this: zplug "sindresorhus/pure", use:"{async,pure}.zsh". The autoload approach sounds good too, though I don't understand if pl9k does that when loaded is there any impact on a user that autoloads it prior in their .zshrc? Say for several plugins that use it and only having to update one zsh-async, no conflicts I hope if I autoload it earlier before pl9k or another plugin takes the same approach as pl9k with their own copy(potentially different version).

@bhilburn bhilburn mentioned this issue Nov 28, 2016
27 tasks
@bhilburn
Copy link
Member Author

Closing this issue, as @dritter's work on the 'async' branch basically supersedes this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants