| Commit message (Collapse) | Author | Age |
... | |
| | | |
| | | |
| | | | |
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.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Problem: as fileio is cached and reads blocks this is going to wait
until either EOF or reading enough characters to fill rbuffer. This is
not good when reading user input from stdin as script.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This variant uses `fdopen()` which is not standard, but it fixes problem on my
system. In next commit `scriptin` will use `FileDescriptor*` from os/fileio in
place of `FILE*`.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Check whether `repeated_read_cmd` returned nil and did not actually run nvim or
it did, but still returned nil for whatever reason.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|