aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/os
Commit message (Collapse)AuthorAge
* refactor: fix incorrect use of enum (#30631)zeertzjq2024-10-03
|
* refactor(event): change last use of klist to kvecbfredl2024-09-28
| | | | | | | | | | | loop->children might have been a linked list because used to be modified in place while looped over. However the loops that exists rather schedules events to be processed later, outside of the loop, so this can not happen anymore. When a linked list is otherwise useful it is better to use lib/queue_defs.h which defines an _intrusive_ linked list (i e it doesn't need to do allocations for list items like klist ).
* refactor(api)!: rename Dictionary => DictJustin M. Keyes2024-09-23
| | | | | | | | | | | | | | In the api_info() output: :new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val') ... {'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1} The `ArrayOf(Integer, 2)` return type didn't break clients when we added it, which is evidence that clients don't use the `return_type` field, thus renaming Dictionary => Dict in api_info() is not (in practice) a breaking change.
* fix(coverity): CID 509571 Uninitialized variables #30395Justin M. Keyes2024-09-18
| | | | | | | | | | | | /src/nvim/os/pty_proc_unix.c: 416 in pty_proc_init() 410 { 411 PtyProc rv; 412 rv.proc = proc_init(loop, kProcTypePty, data); 413 rv.width = 80; 414 rv.height = 24; 415 rv.tty_fd = -1; >>> CID 509571: Uninitialized variables (UNINIT) >>> Using uninitialized value "rv". Field "rv.winsize" is uninitialized. 416 return rv;
* refactor: rename "process" => "proc" #30387Justin M. Keyes2024-09-15
| | | | | | | | | | | | Problem: - "process" is often used as a verb (`multiqueue_process_events`), which is ambiguous for cases where it's used as a topic. - The documented naming convention for processes is "proc". - `:help dev-name-common` - Shorter is better, when it doesn't harm readability or discoverability. Solution: Rename "process" => "proc" in all C symbols and module names.
* refactor(stream.c): unused params in stream_close #30356Justin M. Keyes2024-09-12
|
* feat(log): use "ui" as default name for TUI client #30345Justin M. Keyes2024-09-11
| | | | | | | | | | | | | The default "session name" for the builtin TUI is "ui". before: INF 2024-09-10T14:57:35.385 hello.sock os_exit:692: Nvim exit: 1 INF 2024-09-10T14:57:35.388 ?.4543 os_exit:692: Nvim exit: 1 after: INF 2024-09-10T14:59:19.919 hello.sock os_exit:692: Nvim exit: 1 INF 2024-09-10T14:59:19.922 ui.5684 os_exit:692: Nvim exit: 1
* refactor(os/input.c): rename os_inchar => input_get #30327Justin M. Keyes2024-09-10
| | | | | | | | | | | Problem: The name `os_inchar` (from Vim's old `mch_inchar`) is ambiguous: "inchar" sounds like it could be reading or enqueuing (setting) input. Its docstring is also ambiguous. Solution: - Rename `os_inchar` to `input_get`. - Write some mf'ing docstrings. - Add assert() in TRY_READ().
* fix(startup): server fails if $NVIM_APPNAME is relative dir #30310Justin M. Keyes2024-09-08
| | | | | | | | | | | | | | | | | | Problem: If $NVIM_APPNAME is a relative dir path, Nvim fails to start its primary/default server, and `v:servername` is empty. Root cause is d34c64e342dfba9248d1055e702d02620a1b31a8, but this wasn't noticed until 96128a5076b7 started reporting the error more loudly. Solution: - `server_address_new`: replace slashes "/" in the appname before using it as a servername. - `vim_mktempdir`: always prefer the system-wide top-level "nvim.user/" directory. That isn't intended to be specific to NVIM_APPNAME; rather, each *subdirectory* ("nvim.user/xxx") is owned by each Nvim instance. Nvim "apps" can be identified by the server socket(s) stored in those per-Nvim subdirs. fix #30256
* refactor: adopt termkey and eliminate duplicate codedundargoc2024-09-05
| | | | | | | | | Termkey is abandoned and it's now our code, so there's no reason not to treat it as such. An alternative approach could be to have a proper repo that we maintain such as with unibilium, although with this approach we can make a few assumptions that will allow us to remove more code. Also eliminate duplicate code from both termkey and libvterm.
* docs: misc #28970Justin M. Keyes2024-09-01
|
* docs: misc (#29719)dundargoc2024-08-29
| | | | | | | | | Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com> Co-authored-by: Lauri Heiskanen <lauri.heiskanen@nimble.fi> Co-authored-by: Piotr Doroszewski <5605596+Doroszewski@users.noreply.github.com> Co-authored-by: Tobiasz Laskowski <tobil4sk@outlook.com> Co-authored-by: ariel-lindemann <41641978+ariel-lindemann@users.noreply.github.com> Co-authored-by: glepnir <glephunter@gmail.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
* build(deps): vendor libvterm at v0.3.3Christian Clason2024-08-10
| | | | | | | | Problem: Adding support for modern Nvim features (reflow, OSC 8, full utf8/emoji support) requires coupling libvterm to Nvim internals (e.g., utf8proc). Solution: Vendor libvterm at v0.3.3.
* vim-patch:8.2.4860: MS-Windows: always uses current directory for executableszeertzjq2024-08-09
| | | | | | | | | | | | Problem: MS-Windows: always uses current directory for executables. Solution: Check the NoDefaultCurrentDirectoryInExePath environment variable. (Yasuhiro Matsumoto, closes vim/vim#10341) https://github.com/vim/vim/commit/05cf63e9bdca1ac070df3e7d9c6dfc45e68ac916 Omit doc change: override in later doc update. Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
* refactor(shada): rework msgpack decoding without msgpack-cbfredl2024-08-05
| | | | | | | This also makes shada reading slightly faster due to avoiding some copying and allocation. Use keysets to drive decoding of msgpack maps for shada entries.
* refactor(declarations): also generate prototypes for functions in headersbfredl2024-07-13
| | | | | | | | | | | Before this change, "static inline" functions in headers needed to have their function attributes specified in a completely different way. The prototype had to be duplicated, and REAL_FATTR_ had to be used instead of the public FUNC_ATTR_ names. TODO: need a check that a "header.h.inline.generated.h" file is not forgotten when the first "static inline" function with attributes is added to a header (they would just be silently missing).
* refactor: Windows tilde expansion followup (#29380)Rafael Kitover2024-06-18
| | | | | | | | | | | | | | | | | | | | | | | Followup to #28515: Rename the static os_homedir() to os_uv_homedir() to emphasize that it is a wrapper around a libuv function. Add the function os_get_homedir() to os/env.c to return the cached homedir value as a const. Must be called after homedir is initialized or it fails. The difference between this function and the static os_uv_homedir() is that the latter gets the homedir from libuv and is used to initialize homedir in init_homedir(), while os_get_homedir() just returns homedir as a const if it's initialized and is public. Use the os_get_homedir() accessor for ~/ expansion on Windows to make the code more concise. Add a Windows section to main_spec.lua with tests for expanding ~/ and ~\ prefixes for files passed in on the command-line. Signed-off-by: Rafael Kitover <rkitover@gmail.com>
* Merge pull request #29241 from bfredl/shadapackbfredl2024-06-14
|\ | | | | refactor(shada): use msgpack_sbuffer less
| * refactor(shada): use msgpack_sbuffer lessbfredl2024-06-11
| | | | | | | | | | | | | | Work towards getting rid of libmsgpack depedency eventually. msgpack_sbuffer is just a string buffer, we can use our own String type.
* | refactor(memory): use builtin strcat() instead of STRCAT()bfredl2024-06-11
|/ | | | | | | | The latter was mostly relevant with the past char_u madness. NOTE: STRCAT also functioned as a counterfeit "NOLINT" for clint apparently. But NOLINT-ing every usecase is just the same as disabling the check entirely.
* refactor(os/shell): we have DynamicBuffer at homebfredl2024-06-09
| | | | DynamicBuffer at home: KVÄCK
* refactor(io): make rstream use a linear bufferbfredl2024-06-08
| | | | | | | | | If you like it you shouldn't put a ring on it. This is what _every_ consumer of RStream used anyway, either by calling rbuffer_reset, or rbuffer_consumed_compact (same as rbuffer_reset without needing a scratch buffer), or by consuming everything in each stream_read_cb call directly.
* fix(fileio): copy to correct buffer position when readingbfredl2024-06-06
| | | | | | fixes #29186 (likely) fixup for #29093 064483a2b
* fixup: apply the change on more filesJames Tirta Halim2024-06-04
|
* Merge pull request #29124 from bfredl/inputringbfredl2024-06-02
|\ | | | | refactor(input): don't use a ring for input
| * refactor(input): don't use a ring for inputbfredl2024-06-01
| | | | | | | | Since paste data is handled via a separate channel, the data processed via `input_buffer` is typically just explicit keys as typed in by the user. Therefore it should be fine to use `memmove()` to always put the remaining data in front when refilling the buffer.
* | refactor: move shared messages to errors.h #26214Justin M. Keyes2024-06-01
|/
* refactor(io): separate types for read and write streamsbfredl2024-05-31
| | | | | | | | | | | | This is a structural refactor with no logical changes, yet. Done in preparation for simplifying rstream/rbuffer which will require more state inline in RStream. The initial idea was to have RStream and WStream as sub-types symetrically but that doesn't work, as sockets are both reading and writing. Also there is very little write-specific state to start with, so the benefit of a separate WStream struct is a lot smaller. Just document what fields in `Stream` are write specific.
* refactor(fileio): use a linear buffer for FileDescriptorbfredl2024-05-30
| | | | | | | | | | | | | | | | Using a ring buffer for buffered synchronous fileio is just unnecessary complexity. - when reading, we always consume the _entire_ buffer before getting into syscalls. Thus we reset the buffer to its initial position before when we actually read. - when writing and buffer is full, we always flush the entire buffer before starting to buffer again. So we can reset the buffer to its initial state. Also no static buffers are needed for writing and skipping. Needing an extra copy for each write completely defeated the purpose of a ring buffer (if there had been one)
* Merge pull request #29016 from bfredl/shadareaderbfredl2024-05-29
|\ | | | | refactor(shada): remove ShaDaReadDef secondary wrapper
| * refactor(shada): remove ShaDaReadDef secondary wrapperbfredl2024-05-28
| | | | | | | | | | | | `FileDescriptor` is already a wrapper around an fd and a buffer. By allowing to just use the buffer without an fd, it can already handle in-memory reads.
* | refactor(fileio): remove useless use of FileDescriptorbfredl2024-05-28
|/ | | | | | | FileDescriptor is used to buffer togheter many small writes to fewer syscalls. if the data to write already is in a single buffer, it is perfectly fine to just use os_write directly (which will take care of the reverse problem: splitting a too big write into many syscalls)
* fix(path): avoid chdir() when resolving path (#28799)zeertzjq2024-05-17
| | | | | | | | | | | | | | | | | | | | | | Use uv_fs_realpath() instead. It seems that uv_fs_realpath() has some problems on non-Linux platforms: - macOS and other BSDs: this function will fail with UV_ELOOP if more than 32 symlinks are found while resolving the given path. This limit is hardcoded and cannot be sidestepped. - Windows: while this function works in the common case, there are a number of corner cases where it doesn't: - Paths in ramdisk volumes created by tools which sidestep the Volume Manager (such as ImDisk) cannot be resolved. - Inconsistent casing when using drive letters. - Resolved path bypasses subst'd drives. Ref: https://docs.libuv.org/en/v1.x/fs.html#c.uv_fs_realpath I don't know if the old implementation that uses uv_chdir() and uv_cwd() also suffers from the same problems. - For the ELOOP case, chdir() seems to have the same limitations. - On Windows, Vim doesn't use anything like chdir() either. It uses _wfullpath(), while libuv uses GetFinalPathNameByHandleW().
* refactor(build): make all generated c files headersbfredl2024-04-27
| | | | | | | | | | | | | | | There's no "rule" or bad practice or whatever that says we cannot generate c files. it is is just that we have ~20 generated headers and ~2 generated sources and there is nothing in these two generated source files which sets them aparts. Lua bindings are not different from rpc bindings, and pathdef is not different from versiondef. So to simplify build logic and ease the future port to build.zig, streamline the build to only have generated headers, no direct generated .c files. Also "nlua_add_api_functions" had its prototype duplicated twice which defeated the point of having mandatory prototypes (one source of truth).
* refactor: add xmemcpyz() and use it in place of some xstrlcpy() (#28422)zeertzjq2024-04-20
| | | | | | Problem: Using xstrlcpy() when the exact length of the string to be copied is known is not ideal because it requires adding 1 to the length and an unnecessary strlen(). Solution: Add xmemcpyz() and use it in place of such xstrlcpy() calls.
* build(windows): set longPathAware in manifest #28389Luna Saphie Mittelbach2024-04-18
| | | | | | | | | ref https://github.com/neovim/neovim/issues/28384 Allows Windows file APIs (and anything that uses them) to bypass the 260-character `MAX_PATH` limitation on Windows 10 1607 or later. NOTE: This change by itself does not change the behaviour of running Neovim. The system must also have the Windows registry key `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled` set to a `REG_DWORD` with value 1. See https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell#enable-long-paths-in-windows-10-version-1607-and-later for more information.
* fix(path): check return value of append_path() (#28309)Joey Gouly2024-04-13
| | | | | | | | | | | | | | | | | | | | | | | If the filename passed to vim_FullName() is a relative directory, and does not exist, it is appended to the current working directory. Since the return value of append_path() was ignored, and if the buffer length was too small to fit getcwd() + dirname(filename), it would still try to append the basename(filename). This was manifesting as a failure in test/unit/path_spec.lua in: itp('fails and uses filename if given filename contains non-existing directory', .. This failure occurs when running the tests from directory with a short path such as: /work/src/nv test/unit/path_spec.lua:420: Expected objects to be the same. Passed in: (string) '/work/src/nv/test.file' Expected: (string) 'non_existing_dir/test.file' This return value for the second call to append_path() to append basename(filename) was checked, and this is where it would fail for normal / longer getcwd()s.
* vim-patch:8.1.0815: dialog for file changed outside of Vim not tested (#28184)zeertzjq2024-04-05
| | | | | | | | | Problem: Dialog for file changed outside of Vim not tested. Solution: Add a test. Move FileChangedShell test. Add 'L' flag to feedkeys(). https://github.com/vim/vim/commit/5e66b42aae7c67a3ef67617d4bd43052ac2b73ce Co-authored-by: Bram Moolenaar <Bram@vim.org>
* fix(stdpath): remove duplicate directories (#26653)Raphael2024-04-03
|
* test: add a bit more testing for vim.on_key() (#28095)zeertzjq2024-03-29
| | | | | Also: - Don't use NUMBUFLEN as buffer length as its unrelated. - Restore accidentally removed comment from last commit.
* vim-patch:9.1.0220: Few typos in source and test files (#28076)zeertzjq2024-03-28
| | | | | | | | Problem: Typos in code and tests. Solution: Fix typos (zeertzjq). closes: vim/vim#14321 https://github.com/vim/vim/commit/c029c131ea7822514d67edb9be2de76d076aa267
* docs: fix typos (#27868)dundargoc2024-03-28
| | | | | | | | | Co-authored-by: ite-usagi <77563904+ite-usagi@users.noreply.github.com> Co-authored-by: v-sim <56476039+v-sim@users.noreply.github.com> Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Quico Augustijn <quico.public@gmail.com> Co-authored-by: nhld <nahnera@gmail.com> Co-authored-by: francisco souza <108725+fsouza@users.noreply.github.com>
* vim-patch:9.1.0162: problem with writing extended attributes on failure (#27800)zeertzjq2024-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: problem with writing extended attributes on failure Solution: Change return type to ssize_t and check listxattr's return value correctly on failure (Paul Tagliamonte) The existing logic will return when the listxattr call returns with the errno set to ENOTSUP (or a size of 0 bytes), without checking to see if listxattr actually failed. listxattr can fail with at least E2BIG, ENOTSUP, ERANGE, or anything that `stat(2)` can fail with (in my case; ENOENT from stat). The returned size is stored to a size_t, but the return type is a ssize_t. On failure, listxattr returns -1, which will get translated to size_t's MAX. If the listxattr call failed with anything other than ENOTSUP, this triggers a request for size_t MAX bytes. This means that, if the listxattr call fails with anything other than ENOTSUP on save, vim will error with `E342: Out of memory! (allocating 18446744073709551615 bytes)` (keen observers will note 18446744073709551615 is 0xffffffffffffffff) In reality, this is likely masking a different (usually filesystem?) error -- but at least it's an error being pushed to the user now, and we don't try to allocate size_t MAX bytes. I've opted to change the type that we store listxattr to from size_t to ssize_t, to match listxattr(2)'s signature, and to check for the -1 return value. Additionally, I've removed the errno check -- if we get a listxattr failure for any reason, we may as well bail without trying; it's not like we can even recover. closes: vim/vim#14169 https://github.com/vim/vim/commit/14759ded57447345ba11c11a99fd84344797862c Co-authored-by: Paul R. Tagliamonte <paultag@gmail.com>
* vim-patch:9.1.0161: expand() removes slash after env variable that ends with ↵zeertzjq2024-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | colon (#27791) Problem: expand() removes a slash after an environment variable that ends with a colon on Windows. Solution: Check the correct char for a colon (zeertzjq) closes: vim/vim#14161 Note: Vim still removes the path-separator at the end, if another path separator follows directly after it, e.g. on: ``` echo $FOO='/usr/' echo expand('$FOO/bar') == '/usr/bar' ``` see: ,----[ misc1.c:1630 ] | // if var[] ends in a path separator and tail[] starts | // with it, skip a character | if (after_pathsep(dst, dst + c) | #if defined(BACKSLASH_IN_FILENAME) || defined(AMIGA) | && (dst == save_dst || dst[-1] != ':') | #endif | && vim_ispathsep(*tail)) | ++tail; `---- https://github.com/vim/vim/commit/13a014452a7a020a119ac555a690c65b41f3126d Cherry-pick test_expand.vim change from patch 9.0.1257.
* vim-patch:8.2.5077: various warnings from clang on MS-Windows (#27773)zeertzjq2024-03-08
| | | | | | | | Problem: Various warnings from clang on MS-Windows. Solution: Avoid the warnings. (Yegappan Lakshmanan, closes vim/vim#10553) https://github.com/vim/vim/commit/a34b4460c2843c67a35a2d236b01e6cb9bc38734 Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
* fix(process): avoid potential data race on exit (#27769)zeertzjq2024-03-08
| | | | | On exit, pty_process_close() may be called after pty_process_finish1() but before start_wait_eof_timer(), in which case the timer shouldn't be started because pty_process_close() has already closed it.
* fix(process): close handles and timer in pty_process_close() (#27760)zeertzjq2024-03-07
| | | This should prevent use-after-free on exit on Windows.
* refactor(metadata): generate all metadata in luabfredl2024-02-28
| | | | | | | | Then we can just load metadata in C as a single msgpack blob. Which also can be used directly as binarly data, instead of first unpacking all the functions and ui_events metadata to immediately pack it again, which was a bit of a silly walk (and one extra usecase of `msgpack_rpc_from_object` which will get yak shaved in the next PR)
* Merge pull request #27599 from bfredl/nofileallocbfredl2024-02-26
|\ | | | | refactor(fileio): remove API shell layer encouraging unnecessary allocations
| * refactor(fileio): remove API shell layer encouraging unnecessary allocationsbfredl2024-02-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Functions like file_open_new() and file_open_fd_new() which just is a wrapper around the real functions but with an extra xmalloc/xfree around is an anti-pattern. If the caller really needs to allocate a FileDescriptor as a heap object, it can do that directly. FileDescriptor by itself is pretty much a pointer, or rather two: the OS fd index and a pointer to a buffer. So most of the time an extra pointer layer is just wasteful. In the case of scriptin[curscript] in getchar.c, curscript used to mean in practice: N+1 open scripts when curscript>0 zero or one open scripts when curscript==0 Which means scriptin[0] had to be compared to NULL to disambiguate the curscript=0 case. Instead, use curscript==-1 to mean that are no script, then all pointer comparisons dissappear and we can just use an array of structs without extra pointers.
generated by cgit (git 2.34.1) at 2026-06-13 17:13:03 +0000