Reasoning:
- No need to check for terminal size.
- No need to mess with terminal title.
- Allows old tests to timeout with the rest of the build proceeding.
- Less and less messy output to travis log.
- Opens a path allowing old tests run in parallel. Though last bit needs test
refactoring.
This does not change the behavior but centralizes column size for future use
(like dynamic signcolumn width depending on the maximum number of signs on a line).
The returned value is limited by the size of the `extra` tab in win_line
(currently allows for 18 ASCII characters).
TODO: Raymond Chen explains[1] racy behavior of the
CreateToolhelp32Snapshot approach. Better approach:
> create a job object and put process P in it. Then call
> QueryInformationJobObject with JobObjectBasicProcessIdList to get the
> list of child processes.
[1] "Why is CreateToolhelp32Snapshot returning incorrect parent process IDs all of a sudden?"
https://blogs.msdn.microsoft.com/oldnewthing/20150403-00/?p=44313
XXX: comment at https://stackoverflow.com/q/1173342 :
> Windows recycles PIDs quite fast, you have to be extra careful not
> to kill unrelated processes. These APIs will report PPIDs for long
> dead processes whose PIDs may have been recycled. Check the parent
> start date to make sure it is related to the processes you spawned.
UV_PROCESS_DETACHED compels libuv:uv__process_child_init() to call
setsid() in the child just after fork(). That ensures the process and
its descendants are grouped in a separate session (and process group).
The following jobstart() call correctly groups `sh` and `sleep` in a new
session (and process-group), where `sh` is the "session leader" (and
process-group leader):
:call jobstart(['sh','-c','sleep 60'])
SESN PGRP PID PPID Command
30383 30383 30383 3620 │ ├─ -bash
30383 31432 31432 30383 │ │ └─ nvim -u NORC
30383 31432 31433 30383 │ │ ├─ nvim -u NORC
8105 8105 8105 31432 │ │ └─ sh -c sleep 60
8105 8105 8106 8105 │ │ └─ sleep 60
closes#6530
ref: https://stackoverflow.com/q/1046933
ref: https://unix.stackexchange.com/a/404065
Helped-by: Marco Hinz <mh.codebro+github@gmail.com>
Discussion
------------------------------------------------------------------------
On my linux box before this patch, the termclose_spec.lua:'kills job
trapping SIGTERM' test indirectly causes cmake/busted to wait for 60s.
That's because the test spawns a `sleep 60` descendant process which
hangs around even after nvim exits: nvim killed the parent PID, but not
PGID (process-group), so the grandchild "reparented" to init (PID 1).
Session contains processes (and process-groups) which are logically part
of the same "login session". Process-group is a set of
logically/informally-related processes within a session; for example,
shells assign a process group to each "job". Session IDs and PGIDs both
have type pid_t (like PIDs).
These OS-level mechanisms are, as usual, legacy accidents whose purpose
is upheld by convention and folklore. We can use session-level grouping
(setsid), or we could use process-group-level grouping (setpgid).
Vim uses setsid() if available, otherwise setpgid(0,0).
Windows
------------------------------------------------------------------------
UV_PROCESS_DETACHED on win32 sets CREATE_NEW_PROCESS_GROUP flag.
But uv_kill() does not kill the process-group:
https://github.com/nodejs/node/issues/3617
Ideas:
- Set UV_PROCESS_DETACHED (CREATE_NEW_PROCESS_GROUP), then call
GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, pid)
- Maybe won't work because MSDN says "Only processes that share the
same console as the calling process receive the signal."
https://docs.microsoft.com/en-us/windows/console/generateconsolectrlevent
But CREATE_NEW_PROCESS_GROUP creates a new console ...
ref https://stackoverflow.com/q/1453520
- Group processes within a "job". libuv does that *globally* for
non-detached processes: uv__init_global_job_handle.
- Iterate through CreateToolhelp32Snapshot().
- https://stackoverflow.com/q/1173342
- Vim does this, see terminate_all()
Update vim_diff.txt with :lmap differences, update documentation on
'keymap', and add tests.
The tests added are to demonstrate the behaviour specified in the
documentation of :loadkeymap.
This means that the major way that :lmap mappings are applied works as
one would expect with macros.
This also means that having a translation with 'keymap' does not
preclude using mappings in insert mode with :imap.
There is some behaviour that we keep with the recent changes, and some
behaviour that we change.
Instetad of having one failing test covering all behaviour, we split
the test into two.
If the mental model of :lmap mappings is a translation between your
keyboard and vim proper, then they should take preference over :imap
(and other) mappings. This patch makes that happen.
The mental model of :lmap and 'keymap' is of a transformation done
before anything else. Hence when recording a macro, or writing to a
scriptfile, the transformed keys should be recorded instead of the keys
before the transformation.
vim-patch:8.0.0262: Farsi support is barely tested
Problem: Farsi support is barely tested.
Solution: Add more tests for Farsi. Clean up the code.
ddf662a1c8
vim-patch:8.0.0263: Farsi support is not tested enough
Problem: Farsi support is not tested enough.
Solution: Add more tests for Farsi. Clean up the code.
80627cf51f
