Problem: "verbose pwd" shows confusing info when :lcd does not change
directory.
Solution: Clear last_chdir_reason also when the directory does not change.
(closesvim/vim#9160)
64be6aa3a5
This only ports the tests, as this is already Nvim's behavior.
Problem: getcwd() is unclear about how 'autochdir' is used.
Solution: Update the help for getcwd(). Without any arguments always return
the actual current directory. (closesvim/vim#9142)
851c7a699a
Problem: ":verbose pwd" does not mention 'autochdir' was applied.
Solution: Remember the last chdir was done by 'autochdir'. (issue vim/vim#9142)
0526815c15
Problem: Problem with :cd when editing file in non-existent directory. (Yee
Cheng Chin)
Solution: Prepend the current directory to get the full path. (closesvim/vim#8903)
c6376c7984
Problem: 'listchars' should be window-local.
Solution: Make 'listchars' global-local. (Yegappan Lakshmanan, Marco Hinz,
closesvim/vim#5206, closesvim/vim#7850)
eed9d46293
Nvim already has this feature, but it implements :set listchars the same
as :setglobal listchars, which is incorrect. Vim's implementation of
:set listchars is correct: using :set listchars clears local value.
Make the bufnr argument have similar semantics across API functions;
namely, a nil value means "all buffers" while 0 means "current buffer".
This increases the flexibility of the API by allowing functions such as
enable() and disable() to apply globally or per-namespace, rather than
only on a specific buffer.
If a LSP server sent a workspace edit containing a rename the buffers
file name changed without the server receiving a close notification for
the old buffer and without the client properly re-attaching on the new
file.
This affected `Move` code-actions in nvim-jdtls, but also
`vim.lsp.buf.rename` on a class level.
* use codeunits/points instead of byte ranges when applicable
* take into account different file formats when computing range and
sending text (dos, unix, and mac supported)
* add tests of incremental sync
Also fix a few other small bugs regarding saving and restoring extmarks.
In particular, now that the virtual text and underline handlers have
their own dedicated namespaces, they should be responsible for saving
and restoring their own extmarks. Also fix the wrong argument ordering
in the call to `clear_diagnostic_cache` in the `on_detach` callback.
* vim.ui.input is an overridable function that prompts for user input
* take an opts table and the `on_confirm` callback, see `:help vim.ui.input` for more details
* defaults to a wrapper around vim.fn.input(opts)
* switches the built-in client's rename handler to use vim.ui.input by default
vim.str_utf_{start,end} return the offset from the current position to
the start and end of the current utf-character (nearest codepoint)
respectively.
Problem:
1. "unpack" has an unrelated meaning in Lua:
https://www.lua.org/manual/5.1/manual.html#pdf-unpack
2. We already have msgpackparse()/msgpackdump() and
json_encode()/json_decode(), so introducing another name for the same
thing is entropy.
Solution:
- Rename vim.mpack.pack/unpack => vim.mpack.encode/decode
Caveat:
This is incongruent with the `Unpacker` and `Packer` functions.
- It's probably too invasive to rename those.
- They also aren't part of our documented interface.
- This commit is "reversible" in the sense that we can always revert
it and add `vim.mpack.encode/decode` as _aliases_ to
`vim.mpack.pack/unpack`, at any time in the future, if we want
stricter fidelity with upstream libmpack. Meanwhile,
`vim.mpack.encode/decode` is currently the total _documented_
interface of `vim.mpack`, so this change serves the purpose of
consistent naming in the Nvim stdlib.
Rather than treating virtual_text, signs, and underline specially,
introduce the concept of generic "handlers", of which those three are
simply the defaults bundled with Nvim. Handlers are called in
`vim.diagnostic.show()` and `vim.diagnostic.hide()` and are used to
handle how diagnostics are displayed.
Problem: Filler lines are incorrect for other window in diff mode after
making a change.
Solution: Copy filler lines from the current window. (closesvim/vim#8809)
841c225b9e
"works with &opt" is flaky; now it always fails after #15999 for some reason.
This test was skipped in #10773 due to previous flakiness, but after the switch away from appveyor
the check no longer works. Just skip for any CI running the MSVC_32 job.
