Consider the following script:
% powerline-daemon -s powerline-test
% powerline --socket powerline-test -p/dev/null shell left
Config file not found in search paths (/dev/null): config.json
% powerline --socket powerline-test shell left
Config file not found in search paths (/dev/null): config.json
Note the problem: second call to powerline does not use offending path, but it
still emits the error “Config file not found in search paths”.
Now imports follow the following structure:
1. __future__ line: exactly one line allowed:
from __future__ import (unicode_literals, division, absolute_import, print_function)
(powerline.shell is the only exception due to problems with argparse).
2. Standard python library imports in a form `import X`.
3. Standard python library imports in a form `from X import Y`.
4. and 5. 2. and 3. for third-party (non-python and non-powerline imports).
6. 3. for powerline non-test imports.
7. and 8. 2. and 3. for powerline testing module imports.
Each list entry is separated by exactly one newline from another import. If
there is module docstring it goes between `# vim:` comment and `__future__`
import. So the structure containing all items is the following:
#!/usr/bin/env python
# vim:fileencoding=utf-8:noet
'''Powerline super module'''
import sys
from argparse import ArgumentParser
import psutil
from colormath.color_diff import delta_e_cie2000
from powerline.lib.unicode import u
import tests.vim as vim_module
from tests import TestCase
.
- Fixes lines where line with N tab indent is followed by a line with N+2 tab
indent or greater (most of such lines were already fixed in
ae92d83eae, but regex used there has one flow:
it does not catches lines where N=0 for which case first `\+` needs to be
replaced with `*`).
- Replace print(…, file=sys.stderr) with sys.stderr.write in powerline-daemon.
Assuming ascii was expected to be used when LANG=C it did not work in any case:
in this case preferred encoding is “ANSI_X3.4-1968”. Same for
`sys.getfilesystemencoding()`.
This byte is useless and can be seen in zsh output (strange that it did not
cause bugs so far, at least none I know about). It may have been needed if any
client was supposed to hold connection with daemon for a few runs, but all
current clients work in “request → output response → exit” fashion without
caring about terminating newline and definitely without preserving connection to
daemon accross runs.
Reason: there is no `file()` in Python 3.
Fix was originally presented by @kovidgoyal in [3deb69][1], but I cannot
cherry-pick this commit, because its commit message is highly undescriptive.
Fixes#1008
[1]: 3deb6988c8
It took 2/3 of do_render call according to profiler. New variant takes only 1/6.
WARNING: This commit will break all powerline installations with running daemon
because it changes communication protocol. You must kill and restart all your
powerline daemons for powerline to function properly.
Highlight @kovidgoyal
Minor changes have been applied:
- Removed copyright info and GPL 3 license since Powerline is MIT (needs
confirmation from kovidgoyal before merge)
- The `powerline-client` script is renamed to `powerline`, and calls the
daemon or `powerline-render` (the previous `powerline`) to render
a statusline
- Minor coding style corrections to match the rest of the project
- Python 3 support is removed for now due to setuptools failing with
binary scripts
Todo:
- Automatically attempt to launch powerline-daemon the first time
powerline is run if the daemon isn't already running?
- pip install -e fails with binary files (it appears that pip recodes
the powerline binary to ASCII, the compiled powerline script must be
copied manually to ~/.local/bin after pip install -e has been run)
ZyX
Kim Silkebækken