Before this commit, man#init_pager() always tries to scrape the manpage
name and set the buffer name. That's much less important than avoiding
duplicate buffers and E95. And it doesn't seem to be necessary, usually.
Steps to reproduce:
$ export MANPAGER="nvim -c 'set ft=man' -"
$ man sleep
:Man sleep
Error detected while processing function man#init_pager:
line 15:
E95: Buffer with this name already exists
:ls!
1 h- "man://SLEEP(1)" line 4
2 %a- "man://sleep(1)" line 1
Despite #9095, `brew upgrade python` broke again, somehow.
We should not bother attempting to force a python version. Instead use
whatever python Travis provides on the macOS image.
Avoid clearing the screen in most situations. NOT_VALID should be
equivalent to CLEAR unless some external force messed up the terminal,
for these situations <c-l> and :mode will still clear the screen.
Also eliminate some obsolete code in screen.c, that dealt with that in
vim drawing window 1 can mess up window 2, but this never happens in
nvim.
But what about slow terminals? There is two common meanings in which
a terminal is said to be "slow":
Most commonly (and in the sense of vim:s nottyfast) it means low
bandwidth for sending bytes from nvim to the terminal. If the screen is
very similar before and after the update_screen(CLEAR) this change
should reduce bandwidth. If the screen is quite different, but there is
no new regions of contiguous whitespace, clearing doesn't reduce
bandwidth significantly. If the new screen contains a lot of whitespace,
it will depend of if vsplits are used or not: as long as there is no
vsplits, ce is used to cheaply clear the rest of the line, so
full-screen clear is not needed to reduce bandwith. However a left
vsplit currently needs to be padded with whitespace all the way to the
separator. It is possible ec (clear N chars) can be used to reduce
bandwidth here if this is a problem. (All of this assumes that one
doesn't set Normal guibg=... on a non-BCE terminal, if you do you are
doomed regardless of this change).
Slow can also mean that drawing pixels on the screen is slow. E-ink
screens is a recent example. Avoiding clearing and redrawing the
unchanged part of the screen will always improve performance in these
cases.
For each package manager,
1. Check if they are executable before starting a job.
2. Check if the job opts are set before checking the job status
TODO: Validate the job id.
Prioritize npm because it's faster than yarn.
Reindent the code to 2-space indent.
PR #9087 changed the error string by removing 'Running', breaking the
MSBuild hack detecting failure for functional tests. If stdout or stderr
has a line with 'functional tests failed with error', fail the build.
clang scan-build noticed that find_command() may bitmask `eap->flags`.
cmd_can_preview() only uses `ea.cmdidx`, but let's fix the warning...
Found by clang scan-build 5.0
mandoc may not handle quoted MANPAGER arguments correctly. E.g. with
export MANPAGER='nvim -u NORC -c "set ft=man"'
mandoc treats `"set` and `ft=man"'` as separate tokens.
To workaround that, provide :Man! so that MANPAGER can avoid quoting.
closes#9120
fix#9050
Q: (from From #7891)
> It turns out there's a difference between executing
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> and /usr/bin/clang. CMake was picking up the former and with that it left off
> a key include path. Why?
A: /usr/bin/clang is a shim that uses libxcselect/libxcrun under the hood.
$ otool -L /usr/bin/clang
/usr/bin/clang:
/usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
From https://macops.ca/developer-binaries-on-os-x-xcode-select-and-xcrun/ :
> this shim binary loads functions in libxcselect.dylib that can locate the
> path to the real binary, depending on how the system has been configured. One
> part of this process is to check whether this path contains
> usr/lib/libxcrun.dylib, and the xcrun tool, in which case it will invoke
> xcrun to run the binary.
> ...
> (If all of this isn’t yet enough indirection for you, /usr/bin/xcrun itself
> is a shim, and so libxcselect.dylib contains code to detect whether the
> executed xcrun is a shim. Look for the __xcrun_shim segment in the __DATA
> section output by the command: pagestuff /usr/bin/xcrun -a.)
Sometimes 008_autocommands_spec fails like this:
[ RUN ] autocommands that delete and unload buffers: BufUnload, VimLeave: -- Output to stderr:
CMake Error at /home/travis/build/neovim/neovim/cmake/RunTests.cmake:53 (message):
functional tests failed with error: 1
The final :quit + wait() is a race. Use command() instead, which is
synchronous. Use command('silent! ...') everywhere else too, because
it's clearer instead of feeding input and clearing the expected errors
with CTRL-L.
Problem: Using try/catch in timer does not prevent it from being stopped.
Solution: Reset the exception context and use did_emsg instead of
called_emsg.
e723c42836
Problem: Can't use input() in a timer callback. (Cosmin Popescu)
Solution: Reset vgetc_busy and set timer_busy. (Ozaki Kiichi, closesvim/vim#1790,
closesvim/vim#1129)
1e8e14552e
Problem: Cursorline not removed when using 'cursorbind'. (Justin Keyes)
Solution: Store the last cursor line per window. (closesvim/vim#3488)
4a5abbd613
In the 20180331 release, the format was slightly changed:
> 20180331
> + improve terminfo write/read by modifying the fourth item of the
> extended header to denote the number of valid strings in the extended
> string table (prompted by a comment in unibilium's sources).
Since the number of valid string capabilities is not necessarily the
same as extstrslen, it's not possible to sanity check the total number
of items up front anymore.
