fix#11753close#11781
The virtualenv troubleshooting in the Python provider health checks is
supposed to help the user determine whether running Python from Neovim
(as in `system('python')` or `system(exepath('python'))`) will use the
correct executable when a virtualenv is active. Currently however, it
issues spurious warnings in legitimate setups, and conversely, fails to
warn about potentially problematic ones.
See https://github.com/neovim/neovim/issues/11753#issuecomment-578715584
for a more detailed analysis, but at a high level, this is due to two
things:
- the virtualenv check is part of the Python provider check defined in
`s:check_python`, which uses a roundabout and sometimes erroneous way of
determining the Python executable
- more generally, it shouldn't be part of the provider check at all,
because it's not really related to the Python *provider*, i.e. the
Python executable which can communicate with Neovim via `pynvim`, but to
the Python the user is editing source files for, which typically
shouldn't even have `pynvim` installed
This patch reimplements the virtualenv check and factors it out into its
own separate function, which is however still kept in
`health/provider.vim` alongside the rest of the Python troubleshooting,
since troubleshooting all Python-related stuff in one place is probably
a good idea in order to alleviate any potential confusion (e.g. users
who run only provider checks might be left wondering whether their
virtualenv Python was properly detected if the report only shows their
global Python as the provider used by Neovim).
Problem: MS-Windows GUI: multibyte chars with a 0x80 byte do not work when
compiled with VIMDLL.
Solution: Adjust the condition for fixing the input buffer. (Ken Takata,
closesvim/vim#4330)
ed5ab2a959
Problem: Recording into a register has focus events. (Michael Naumann)
Solution: Don't record K_FOCUSGAINED and K_FOCUSLOST. (closesvim/vim#3143)
972bfddc6b
Sloppy code inherited from Vim caused user scripts to be able
to observe the cursor line in an invalid intermediary state,
due to Neovim change callbacks being unbuffered unlike Vim listeners.
Manifested in Vimscript executed from the callback possibly erroring
when `:call`:ing any function,
due to the implicit range `curwin->w_cursor.lnum,curwin->w_cursor.lnum`
failing validation.
Fixed by deferring the call to `changed_lines()` until after
`curwin->w_cursor.lnum` gets its correct value.
Problem: Setting 'term' does not store location for termcap options.
Solution: Set the script context for termcap options that are changed when
'term' is set.
35bc7d6c52
Problem: On Windows with the MSVC build, gettext-translation
"Questa è già la" displays as "Questa <e8> gi<e0> la".
Solution: Fix iconv detection iconv when building gettext.
So HAVE_ICONV is correctly defined when building nvim.
* fix gettext mb chars on MSVC
* fix libintl detection failure on MSVC
fixes#11749
- remove `MKSESSION_NL`, `mksession_nl`
- deprecate the "unix" flag of 'sessionoptions'
There is no reason to choose CRLF or LF for session files. Instead just
always write LF.
Problem: When session-restore creates a terminal buffer with command
like `:edit term://.//16450:/bin/bash`, the buffer gets
a different name (depends on PID). Thus the later call to
`bufexists('term://.//16450:/bin/bash)` will return false.
Solution: Force the buffer name with :file. This as least ensures
the same buffer will show in multiple windows correctly, as
expected when saving the session. But it still has problems:
1. the PID in the buffer name is bogus
2. redundant :terminal buffers still hang around
fix#5250
