likely fixes#7768#7913
If multiple internal stream callbacks were recieved before vimL
callbacks got called, only invoke one vimL callback with all data.
win_split() does EMSG for all failure cases, so we don't need to log it.
Easiest thing to do here is ignore the return value (otherwise we need
to do some cleanup and might require some refactoring. jumpto_tag() can
deal with a failed split, so it's no big deal.
Looking at the implementation of u_save suggests that its failure is
a normal and expected situation (e.g. if undo isn't allowed for some
reason, it will fail). Also (most of) the other calls to u_save() in
do_put() return early.
Problem: No autocmd triggered in Insert mode with visible popup menu.
Solution: Add TextChangedP. (Prabir Shrestha, Christian Brabandt,
closesvim/vim#2372, closesvim/vim#1691)
Fix that the TextChanged autocommands are not always triggered
when sourcing a script.
5a09343719
fixes#6974
Before this change, the partial could be freed before the last due
callback got invoked, which caused a use-after-free when the due
callback called the partial.
This condition is not perfectly reliable:
(did_emsg && force_abort && !current_exception)
The more proper way to check for abort-causing non-exception errors is
to set up `msg_list` using the "pattern" given by do_cmdline().
- Return VimL errors instead of generic errors for:
- nvim_call_function
- nvim_call_dict_function
- Fix tests which were silently broken before this change.
This violates #6150 where we agreed not to translate API errors. But
that can be fixed later.
The `internal` param is difficult to explain, and will rarely be
anything but `true`. To avoid it, use a hack: check if the resolved
dict value starts with "function(".
Make `:verbose set ...` show when an option was last modified by an
API client or Lua script/chunk. In the case of an API client, the
channel ID is displayed.
After this change we never release blocks from memory (in practice it
never happened because the memory limits are never reached). Let the OS
take care of that.
---
On today's systems the 'maxmem' and 'maxmemtot' values are huge (4+ GB)
so the limits are never reached in practice, but Vim wastes a lot of
time checking if the limit was reached.
If the limit is reached Vim starts saving pieces of the swap file that were in
memory to the disk. Said in a different way: Vim implements its own
memory-paging mechanism. This is unnecessary and inefficient since the
operating system already has virtual memory and will swap to the disk if
programs start using too much memory.
This change does...
1. Reduce the number of config options and need for documentation.
2. Make the code more efficient as we don't have to keep track of memory
usage nor check if the memory limits were reached to start swapping
to disk every time we need memory for buffers.
3. Simplify the code. Once memfile.c is simple enough it could be
replaced by actual operating system memory mapping (mmap,
MemoryViewOfFile...). This change does not prevent Vim to recover
changes from swap files since the swapping code is never triggered
with the huge limits set by default.
Some terminals don't report which buttons are involved in some mouse
events. For example, the urxvt protocol
(http://www.huge-man-linux.net/man7/urxvt.html section "Mouse
reporting") does not report which button has been released.
In this case libtermkey reports button 0
(http://www.leonerd.org.uk/code/libtermkey/doc/termkey_interpret_mouse.3.html)
Up to now, forward_mouse_event did not handle button==0.
On press events there is not much we can do, and we keep the
current behavior which is dropping the event. But on drag-and-release
events we can compensate by remembering the last button pressed.
fixes#3182 for urxvt
fixes#5400
