Problem: When using a partial on a dictionary it always gets bound to that
dictionary.
Solution: Make a difference between binding a function to a dictionary
explicitly or automatically.
1d429610bf
Problem: Leaking memory when there is a cycle involving a job and a
partial.
Solution: Add a copyID to job and channel. Set references in items referred
by them. Go through all jobs and channels to find unreferenced
items. Also, decrement reference counts when garbage collecting.
107e1eef1d
Problem: Double free when a partial is in a cycle with a list or dict.
(Nikolai Pavlov)
Solution: Do not free a nested list or dict used by the partial.
ddecc25947
Problem: When a dict contains a partial it can't be redefined as a
function. (Nikolai Pavlov)
Solution: Remove the partial when overwriting with a function.
c5fbe8af4c
Problem: When binding a function to a dict the reference count is wrong.
Solution: Decrement dict reference count, only reference the function when
actually making a copy. (Ken Takata)
e4eb6ff089
Problem: Comparing a function that exists on two dicts is not backwards
compatible. (Thinca)
Solution: Only compare the function, not what the partial adds.
f0e86a0dbd
Problem: Having type() handle a Funcref that is or isn't a partial
differently causes problems for existing scripts.
Solution: Make type() return the same value. (Thinca)
953cc7fb13
Problem: Get E923 when using function(dict.func, [], dict). (Kent Sibilev)
Storing a function with a dict in a variable drops the dict if the
function is script-local.
Solution: Translate the function name. Use dict arg if present.
6f2e4b36c9
Problem: Using ":call dict.func()" where the function is a partial does
not work. Using "dict.func()" where the function does not take a
Dictionary does not work.
Solution: Handle partial properly in ":call". (Yasuhiro Matsumoto)
65639032bb
Contains the exit value nvim will use.
Before exiting, it is v:null. That way jobs or autocmds (in VimLeavePre or
VimLeave) can check if Neovim is about to quit and with what exit value.
Closes#4666.
The man plugin uses `v:count == v:count1` to detect if a count was explicitly
given. Unfortunately v:count1 does _not_ default to 1 but 0 during startup.
Now we set v:count1 to 1 early.
Fixes https://github.com/neovim/neovim/issues/5655
* Fix translation of the term 'tag'
Prefer native word instead of transliteration
* Update uk.po automatically
Run make update-po-uk in src/nvim/po
* Update fuzzy translations in uk.po
* Translate missing msgstr
* Fix layout of the front page
* Apply cleanup.vim
Additionally, remove irrelevant and confusing comments
* Copy uk.po into uk.cp1251.po
Problem: Order of matches for 'omnifunc' is messed up. (Danny Su)
Solution: Do not set compl_curr_match when called from complete_check().
(closesvim/vim#1168)
472e85970e
Problem: strcharpart() does not work properly with some multi-byte
characters.
Solution: Use mb_cptr2len() instead of mb_char2len(). (Hirohito Higashi)
fca6600305
this is consistent with vim, and is necessary for plugins that implement
their own input modes using "getchar()" and still want to do async
event processing.
If the backing stream for a :terminal was closed (e.g. if the shell exits
unexpectedly) there may be pending input on the loop which will be processed
before the terminal close event (which is queued on the same loop).
terminal_send checks term->closed but this does not reflect the state of the
underlying streams. The terminal.c module in fact has no knowledge of the
streams (this seems intentional: it is abstracted as TerminalOption.write_cb).
The SIGCHLD handler (pty_process_unix.c) is executed immediately, and it
triggers a stream teardown so Stream.closed=false (TerminalJobData.in.closed).
When the pending writes are handled by eval.c:term_write, wstream_write() aborts
because it sees the closed Stream.
To avoid that, this commit checks Stream.closed in eval:term_write() before writing
to the WStream. (As hinted above, we cannot do this in terminal:terminal_send()
because that module cannot inspect the underlying streams.)
References #5445https://github.com/neovim/neovim/pull/5445#issuecomment-252529766
