| Commit message (Collapse) | Author | Age |
... | |
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
No idea why it thinks that pre is constant expression, but switch() may be
removed.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It appears that transchar() was working under assumption that
`transchar_nonprint()` may be used for multibyte characters while its
documentation stated exact opposite. It was not actually untrue though, except
that longer buffer would be needed then the one stated in documentation. But it
is false now with assert().
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | | |
These kinds of warnings are inevitable for generic macros.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Should actually be silencing that for the sake of the case when `long` is
actually not 64-bit. But it appears that Vim had already defined maximal line
number. And even declared that exact value invalid, so no need in silencing.
|
| | | |
| | | |
| | | | |
Condition was checked in surrounding if().
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | | |
This will be used e.g. by the python client for native asyncio support
|
| | | |
| | | |
| | | | |
closes #8281
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Use it to verify fsync() behavior.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
ref #6725
fsync() is very slow on some systems. And since the parent commit, Nvim
is smarter about flushing files at certain times (e.g. CursorHold),
regardless of whether 'fsync' is enabled. So it's less risky to disable
'fsync'.
Profiling showed slow (2-4s) :write and :quit caused by fsync():
:quit
shada_write_file(NULL, false);
:write + fsync
0 0x00007f72da567b2d in fsync () at ../sysdeps/unix/syscall-template.S:84
1 0x0000000000638970 in uv__fs_fsync (req=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:150
2 uv__fs_work (w=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:953
3 0x0000000000639a70 in uv_fs_fsync (loop=<optimized out>, req=<optimized out>, file=41, cb=0x7f72da567b2d <fsync+45>)
at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:1094
4 0x0000000000573694 in os_fsync (fd=41) at ../src/nvim/os/fs.c:631
5 0x00000000004ec9dc in buf_write (buf=<optimized out>, fname=<optimized out>, sfname=<optimized out>, start=1, end=1997, eap=0x7fffc864c570,
append=<optimized out>, forceit=<optimized out>, reset_changed=<optimized out>, filtering=<optimized out>) at ../src/nvim/fileio.c:3387
6 0x00000000004b44ff in do_write (eap=0x7fffc864c570) at ../src/nvim/ex_cmds.c:1745
...
:write + nofsync
0 0x00007f72da567b2d in fsync () at ../sysdeps/unix/syscall-template.S:84
1 0x0000000000638970 in uv__fs_fsync (req=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:150
2 uv__fs_work (w=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:953
3 0x0000000000639a70 in uv_fs_fsync (loop=<optimized out>, req=<optimized out>, file=36, cb=0x7f72da567b2d <fsync+45>)
at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:1094
4 0x0000000000573694 in os_fsync (fd=36) at ../src/nvim/os/fs.c:631
5 0x0000000000528f5a in mf_sync (mfp=0x7f72d8968d00, flags=5) at ../src/nvim/memfile.c:466
6 0x000000000052d569 in ml_preserve (buf=0x7f72d890f000, message=0) at ../src/nvim/memline.c:1659
7 0x00000000004ebadf in buf_write (buf=<optimized out>, fname=<optimized out>, sfname=<optimized out>, start=1, end=1997, eap=0x7fffc864c570,
append=<optimized out>, forceit=<optimized out>, reset_changed=<optimized out>, filtering=<optimized out>) at ../src/nvim/fileio.c:3071
8 0x00000000004b44ff in do_write (eap=0x7fffc864c570) at ../src/nvim/ex_cmds.c:1745
...
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Vim has the 'swapsync' option which we removed in 62d137ce0969.
Instead let 'fsync' control swapfile-fsync.
These cases ALWAYS force fsync (ignoring 'fsync' option):
- Idle (CursorHold).
- Exit caused by deadly signal.
- SIGPWR signal.
- Explicit :preserve command.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
shada_write_file() is called on exit (:quit and friends), this can be
very slow.
Note: AFAICT Vim (do_viminfo()) does not appear to fsync() viminfo.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | | | |
| | | | |
| | | | | |
fix #5584
|
|/ / / /
| | | |
| | | |
| | | | |
fix #7494
|
| | | |
| | | |
| | | | |
fixes #8290
|
| | | |
| | | |
| | | | |
closes #8303
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Avoid a hot loop in retry(), there's no need to retry more than 50/s.
Also use luv.sleep() to implement sleep() instead of spinning the
event-loop, so events are not silently discarded.
|
| | | |
| | | |
| | | | |
Fixes #7374.
|
|\ \ \ \
| | | | |
| | | | | |
ui_events: correct wrong argument order in resize event
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
test: nodejs_spec: allow more time for nodejs init
|
| | | | | |
|
|/ / / / |
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* Reading from stdin on Windows is fixed in the same way as it was in
#8267.
* The file_read function was returning without filling the
destination buffer when it was called with a non-blocking file
descriptor.
|
| |\ \ \ \ |
|
| | | | | | |
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Assume something with system() if second test hangs as well. Assume something
with reading stdin if not.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|