fix: Handle empty fileencoding by falling back to global encoding #346
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This fix addresses an issue where an error occurs if the buffer's
fileencoding
option is empty during certain operations, such as applying text edits in the LSP. (#344)Context
While similar issues regarding file encodings have been reported and resolved, this specific case occurs when the
fileencoding
of a buffer is not explicitly set. In such cases, the empty string (""
) is returned, leading to failures in functions that expect a valid encoding (e.g.,vim.lsp.util.apply_text_edits
).Changes
encoding
option (vim.o.encoding
) iffileencoding
is empty.encoding
is respected before defaulting to"utf-8"
.Steps to Reproduce
nvim newfile.txt
).fileencoding
, trigger an operation that depends on the file's encoding, such as applying LSP edits.fileencoding
.Fix Explanation
The fix retrieves the
fileencoding
value for the buffer and checks if it is empty. If it is, the globalencoding
setting is used as a fallback. This ensures that the operation continues with a valid encoding, avoiding errors.