Fix setreg() blockwise width calculations with mbyte chars by ychin · Pull Request #16596 · vim/vim
setreg() will automatically calculate the width when a blockwise mode is specified, but it does not properly calculate the line widths of mbyte characters when value is passed as newline-terminated string. It does work when value is passed as a list of lines though. Fix this by properly using the mbyte utiilty to increment the loop counter.
ychin
deleted the
fix-setreg-mbyte-blockwise-width
branch
zeertzjq added a commit to zeertzjq/neovim that referenced this pull request
Feb 9, 2025…blockwise mode
Problem: setreg() doesn't correctly handle mbyte chars in blockwise
mode
Solution: use mb_ptr2len_len function pointer (Yee Cheng Chin)
setreg() will automatically calculate the width when a blockwise mode is
specified, but it does not properly calculate the line widths of mbyte
characters when value is passed as newline-terminated string. It does
work when value is passed as a list of lines though.
Fix this by properly using the mbyte function pointer to increment the
loop counter.
closes: vim/vim#16596
vim/vim@a17f8bf
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
zeertzjq added a commit to zeertzjq/neovim that referenced this pull request
Feb 9, 2025…blockwise mode
Problem: setreg() doesn't correctly handle mbyte chars in blockwise
mode
Solution: use mb_ptr2len_len function pointer (Yee Cheng Chin)
setreg() will automatically calculate the width when a blockwise mode is
specified, but it does not properly calculate the line widths of mbyte
characters when value is passed as newline-terminated string. It does
work when value is passed as a list of lines though.
Fix this by properly using the mbyte function pointer to increment the
loop counter.
closes: vim/vim#16596
vim/vim@a17f8bf
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
ychin added a commit to ychin/macvim that referenced this pull request
Feb 11, 2025Apple "Intelligence" Writing Tools was previously not working correctly with MacVim. When the user chooses to replace the original selection with the updated texts, MacVim mistreats the input and treat them as commands instead of raw texts. The reason was that even though this service uses the NSServicesMenuRequestor API to obtain the selected texts, it does not use it to send over the replacement. Instead, it uses NSTextInput's `insertText:replacementRange` to do so instead, which we never implemented properly. The reason behind this choice was probably because Writing Tools first shows a UI with user interaction and has a delay between obtaining the texts and replacing them, like a regular Services menu. This means the selection may already be invalid by the time it requests a replacement. To fix this, add a new IPC API `replaceSelectedText` to replace the selected texts and redirect `insertText:replacementRange` to use it if the replacement range is non-empty. This isn't the most correct implementation of the protocol but should work in most cases. We don't have a way to implement it "correctly" as MacVim does not have easy access to Vim's internal text storage. Also make sure the Service menu uses this API (for things like "convert to full width" and Traditional/Simplified Chinese conversions). The old method of simple injecting a normal mode command `s` before the text was horribly buggy. It also works with visual block selection properly now. The implementation uses Vim's register put functionality because Vim doesn't have an API to simply replace a block of text, and everything has to go through registers. At the same time, replace the implementation for the old `selectedText` IPC API to not do this, because Vim *did* end an API to do so for obtaining texts (via `getregion()`) and it's more stable to use this than to manually cache/restore registers. Related: vim/vim#16596 (fixes `setreg()` which this uses) Fix macvim-dev#1512
ychin
mentioned this pull request
ychin added a commit to ychin/macvim that referenced this pull request
Feb 11, 2025Apple "Intelligence" Writing Tools was previously not working correctly with MacVim. When the user chooses to replace the original selection with the updated texts, MacVim mistreats the input and treat them as commands instead of raw texts. The reason was that even though this service uses the NSServicesMenuRequestor API to obtain the selected texts, it does not use it to send over the replacement. Instead, it uses NSTextInput's `insertText:replacementRange` to do so instead, which we never implemented properly. The reason behind this choice was probably because Writing Tools first shows a UI with user interaction and has a delay between obtaining the texts and replacing them, like a regular Services menu. This means the selection may already be invalid by the time it requests a replacement. To fix this, add a new IPC API `replaceSelectedText` to replace the selected texts and redirect `insertText:replacementRange` to use it if the replacement range is non-empty. This isn't the most correct implementation of the protocol but should work in most cases. We don't have a way to implement it "correctly" as MacVim does not have easy access to Vim's internal text storage. Also make sure the Service menu uses this API (for things like "convert to full width" and Traditional/Simplified Chinese conversions). The old method of simple injecting a normal mode command `s` before the text was horribly buggy. It also works with visual block selection properly now. The implementation uses Vim's register put functionality because Vim doesn't have an API to simply replace a block of text, and everything has to go through registers. At the same time, replace the implementation for the old `selectedText` IPC API to not do this, because Vim *did* end an API to do so for obtaining texts (via `getregion()`) and it's more stable to use this than to manually cache/restore registers. Related: vim/vim#16596 (fixes `setreg()` which this uses) Fix macvim-dev#1512
ychin
mentioned this pull request
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters