diff options
author | Yuan Fu <casouri@gmail.com> | 2024-09-13 21:42:17 -0700 |
---|---|---|
committer | Yuan Fu <casouri@gmail.com> | 2024-09-14 00:28:23 -0700 |
commit | 6a6d7925c9ddbf558f70932661ee943262aea4ca (patch) | |
tree | 03e91c84614c3ee2afc1c143e6ad74ea7c4f8fab /lisp/emacs-lisp/lisp.el | |
parent | 76faf7e60910ffc29b134fa4d16e3d8c176097a7 (diff) | |
download | emacs-6a6d7925c9ddbf558f70932661ee943262aea4ca.tar.gz emacs-6a6d7925c9ddbf558f70932661ee943262aea4ca.tar.bz2 emacs-6a6d7925c9ddbf558f70932661ee943262aea4ca.zip |
Fix range handling so it works for multibyte buffer (bug#73204)
Here by multibyte buffer I mean buffer that includes non-ASCII
characters.
The problem is illustrated by this comment, which I copied from the
source:
======================================================================
(ref:bytepos-range-pitfall) Suppose we have the following buffer
content ([ ] is a unibyte char, [ ] is a multibyte char):
[a][b][c][d][e][ f ]
and the following ranges (denoted by braces):
[a][b][c][d][e][ f ]
{ }{ }
So far so good, now user deletes a unibyte char at the beginning:
[b][c][d][e][ f ]
{ }{ }
Oops, now our range cuts into the multibyte char, bad!
======================================================================
* src/treesit.c (treesit_debug_print_parser_list): Minor fix.
(treesit_sync_visible_region): Change the way we fixup ranges, instead
of using the bytepos ranges from tree-sitter, we use the cached lisp
charpos ranges.
(treesit_make_ts_ranges): New function.
(Ftreesit_parser_set_included_ranges): Refactor out the new function
treesit_make_ts_ranges.
(Ftreesit_parser_included_ranges): Rather than getting the ranges from
tree-sitter, just return the cached lisp ranges.
* src/treesit.h (Lisp_TS_Parser): Add some comment.
* test/src/treesit-tests.el (treesit-range-fixup-after-edit): New test.
Diffstat (limited to 'lisp/emacs-lisp/lisp.el')
0 files changed, 0 insertions, 0 deletions