Shell prompt has very notable delay

[ZyX-I]

Subj. I can now suggest two things: first, use one call for both PS1 and RPS1 (with eval used to get the result back). It will get rid of the delay between times when PS1 and RPS1 is shown, but won’t get rid of the issue.

Second, make script not evaluated each time prompt is shown. If nothing useful is suggested here or I fail to invent better idea I will probably write a PR with something based on zsh/zpty (overkill, but I see no better options). Bash users will have to invent something on their own.

Though I already though about another idea: writing zsh/zpython C module that will provide commands similar to python/python3 in vim (meaning that python is initialized once module is loaded).

Note: time shows the following for PS1 side:

0,07s user 0,01s system 93% cpu 0,086 total

. I guess “notable delay” consists almost solely of python initialization and I notice it even is PS1 is simple python -c 'print "abc"' (0,02s user 0,00s system 91% cpu 0,026 total).

[Lokaltog]

Yeah, I've noticed this as well.

I don't have deep knowledge about threading and all that stuff, but could it be an idea to have a global Powerline daemon which reads all the config files for all the extensions on startup, caches it and serves it to vim, tmux, shells, etc. on demand? The daemon could maybe create a couple of Unix sockets that can be used for communication so we can just cat the statuslines/prompts to avoid starting Python over and over again? Again, I don't know all the pitfalls of doing this and I'm sure you've thought about it already but I'd like to know your thoughts on this anyways.

Edit: Just saw your comment on stackoverflow, and I can see how the socket solution can be an issue.

[ZyX-I]

For vim you are going to lose a lot on IPC (you need to query vim about some things) or have some computations done in the vim instance (which defeats the point) for nothing: you are not saving yourself from launching interpreter because it is launched only once.

For tmux it is not making much sense as unlike vim tmux does not block me from using itself while statusline is being computed.

For shell it is probably a good choice, but I am not familiar with any IPC except for pipes (and shared memory via multiprocessing.Value). Also I am afraid of GCing stale sockets (it is doable, I already have experience of writing that stuff, but variants I wrote always looked like a hack for me). The ideal variant is zsh/zpython module.

[Lokaltog]

True, it would only have a big benefit for the shell. I don't like that it's limited to zsh though, but it's definitely better than nothing. I don't know anything about zsh/zpython modules so you'd have to implement this.

[ZyX-I]

@Lokaltog There is no zsh/zpython module. But taking if_py* from vim and some module sources it should be relatively easy to create one. I will ask about this on zsh mailing list (I mean, whether it will be included if I write it).

[Lokaltog]

Nice, thanks!

[Lokaltog]

Closing this as the zpython stuff works so well.

[ZyX-I]

It was not merged into mainstream. In fact, I still have not received any reply on the mailing list.

[Lokaltog]

I'm fine with pointing zsh users to your branch until the zsh maintainers have made a decision, but if you disagree I can open this issue again?

[mindfulmonk]

ZyX-I any news if your branch going to be merged with upstream zsh?

[ZyX-I]

@janukevic No news. But I am working on adding python3 support to it (current status: it was added successfully (all but reloading tests pass), but crashes when trying to load unloaded zpython module). When it is finished I will bump the old thread and ask about status.

Note about support: unlike Bram I am not willing to maintain that very long list of symbols loaded from dlopened library. Thus you will have to choose python version you are willing to work with, compiling in both python2 and python3 is not possible.

Branch in question was recently rebased.