bug#67925: 29.1; delete-rectangle fails on multi-column characters

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[awrhygty]

If a multi-column character is crossing the start column of a intended
rectangle, no characters are deleted in the same line.

For example, type 'C-x r d'(delete-rectangle) from column 1 to column 4
of the text below, the second line characters are not deleted.

01234
一二4
01234

result:
04
一二4
04

This does not apply to #'kill-rectangle.
kill-rectangle result:
04
一4
04

To keep the table layout, multi-column characters crossing the start(or
end) column of the rectangle should be replaced with space characters
of the same width before deletion.



In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.3803)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(gnutls network-stream nsm mailalias smtpmail textsec uni-scripts url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util url-parse auth-source cl-seq
eieio eieio-core cl-macs json map byte-opt gv bytecomp byte-compile
url-vars idna-mapping ucs-normalize uni-confusable textsec-check
help-mode pp shadow sort mail-extr emacsbug message mailcap yank-media
puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived
epg rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils term/bobcat japan-util rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 213033 11994)
 (symbols 48 7296 2)
 (strings 32 35632 2250)
 (string-bytes 1 744757)
 (vectors 16 38986)
 (vector-slots 8 785110 26020)
 (floats 8 47 293)
 (intervals 56 590 0)
 (buffers 984 12))

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Eli Zaretskii]

> From: awrhygty@outlook.com
> Date: Wed, 20 Dec 2023 19:58:49 +0900
> 
> 
> If a multi-column character is crossing the start column of a intended
> rectangle, no characters are deleted in the same line.
> 
> For example, type 'C-x r d'(delete-rectangle) from column 1 to column 4
> of the text below, the second line characters are not deleted.
> 
> 01234
> 一二4
> 01234
> 
> result:
> 04
> 一二4
> 04
> 
> This does not apply to #'kill-rectangle.
> kill-rectangle result:
> 04
> 一4
> 04

Thanks.  Does the patch below give good results?

diff --git a/lisp/rect.el b/lisp/rect.el
index 8dc188b..9049e32 100644
--- a/lisp/rect.el
+++ b/lisp/rect.el
@@ -212,7 +212,10 @@ rectangle-dimensions
       (cons width height))))
 
 (defun delete-rectangle-line (startcol endcol fill)
-  (when (= (move-to-column startcol (if fill t 'coerce)) startcol)
+  ;; We use >= here, not =, for characters that use more than one
+  ;; column on display, when STARTCOL is in the middle of such a
+  ;; character.
+  (when (>= (move-to-column startcol (if fill t 'coerce)) startcol)
     (delete-region (point)
 		   (progn (move-to-column endcol 'coerce)
 			  (point)))))

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[awrhygty]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: awrhygty@outlook.com
>> Date: Wed, 20 Dec 2023 19:58:49 +0900
>> 
>> 
>> If a multi-column character is crossing the start column of a intended
>> rectangle, no characters are deleted in the same line.
>> 
>> For example, type 'C-x r d'(delete-rectangle) from column 1 to column 4
>> of the text below, the second line characters are not deleted.
>> 
>> 01234
>> 一二4
>> 01234
>> 
>> result:
>> 04
>> 一二4
>> 04
>> 
>> This does not apply to #'kill-rectangle.
>> kill-rectangle result:
>> 04
>> 一4
>> 04
>
> Thanks.  Does the patch below give good results?
>
> diff --git a/lisp/rect.el b/lisp/rect.el
> index 8dc188b..9049e32 100644
> --- a/lisp/rect.el
> +++ b/lisp/rect.el
> @@ -212,7 +212,10 @@ rectangle-dimensions
>        (cons width height))))
>  
>  (defun delete-rectangle-line (startcol endcol fill)
> -  (when (= (move-to-column startcol (if fill t 'coerce)) startcol)
> +  ;; We use >= here, not =, for characters that use more than one
> +  ;; column on display, when STARTCOL is in the middle of such a
> +  ;; character.
> +  (when (>= (move-to-column startcol (if fill t 'coerce)) startcol)
>      (delete-region (point)
>  		   (progn (move-to-column endcol 'coerce)
>  			  (point)))))

This patch gives similar result of kill-rectangle.
In the example above, I want all '4' characters moved to same column.

And TAB characters crossing the end column are not edited correctly
with delete-rectangle if indent-tabs-mode is on.

012345678
	8(TAB at head)
012345678

The text above is edited to the text below.
45678
	8(TAB at head)
45678

If indent-tabs-mode is off, the result is the text below.
45678
    8(four SPCs)
45678

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Eli Zaretskii]

> From: awrhygty@outlook.com
> Cc: 67925@debbugs.gnu.org
> Date: Thu, 21 Dec 2023 16:30:39 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks.  Does the patch below give good results?
> >
> > diff --git a/lisp/rect.el b/lisp/rect.el
> > index 8dc188b..9049e32 100644
> > --- a/lisp/rect.el
> > +++ b/lisp/rect.el
> > @@ -212,7 +212,10 @@ rectangle-dimensions
> >        (cons width height))))
> >  
> >  (defun delete-rectangle-line (startcol endcol fill)
> > -  (when (= (move-to-column startcol (if fill t 'coerce)) startcol)
> > +  ;; We use >= here, not =, for characters that use more than one
> > +  ;; column on display, when STARTCOL is in the middle of such a
> > +  ;; character.
> > +  (when (>= (move-to-column startcol (if fill t 'coerce)) startcol)
> >      (delete-region (point)
> >  		   (progn (move-to-column endcol 'coerce)
> >  			  (point)))))
> 
> This patch gives similar result of kill-rectangle.
> In the example above, I want all '4' characters moved to same column.

How can that be done, when the first character takes 2 or more
columns?  Deleting the first character is IMO wrong, since the other
lines leave the first character intact.  Adding SPC to other lines is
also wrong, since delete-rectangle is not supposed to _add_ columns.

So I think the effect you see after the patch I proposed is the only
reasonable outcome.  If that is not good enough for keeping the layout
of some table (as you hint in your original report, without showing
any details about the mode used in that case), then Lisp programs
which allow you to keep such tables aligned should be modified to do
something that cannot be done in general by delete-rectangle.

IOW, the general issue in delete-rectangle cannot do anything smarter
than the above, I think, and any solution specific to some particular
implementation or use of rectangles will have to be fixed by code
specific to that particular implementation (if that is some mode that
is part of Emacs).

> And TAB characters crossing the end column are not edited correctly
> with delete-rectangle if indent-tabs-mode is on.
> 
> 012345678
> 	8(TAB at head)
> 012345678
> 
> The text above is edited to the text below.
> 45678
> 	8(TAB at head)
> 45678
> 
> If indent-tabs-mode is off, the result is the text below.
> 45678
>     8(four SPCs)
> 45678

This is a separate issue with the original code.  It also happens with
kill-rectangle, btw.  We could fix it by temporarily binding
indent-tabs-mode to nil inside these commands -- would that be
acceptable?  The result will be that the killed rectangle includes
spaces, not the leading TAB.

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[awrhygty]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: awrhygty@outlook.com
>> Cc: 67925@debbugs.gnu.org
>> Date: Thu, 21 Dec 2023 16:30:39 +0900
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Thanks.  Does the patch below give good results?
>> >
>> > diff --git a/lisp/rect.el b/lisp/rect.el
>> > index 8dc188b..9049e32 100644
>> > --- a/lisp/rect.el
>> > +++ b/lisp/rect.el
>> > @@ -212,7 +212,10 @@ rectangle-dimensions
>> >        (cons width height))))
>> >  
>> >  (defun delete-rectangle-line (startcol endcol fill)
>> > -  (when (= (move-to-column startcol (if fill t 'coerce)) startcol)
>> > +  ;; We use >= here, not =, for characters that use more than one
>> > +  ;; column on display, when STARTCOL is in the middle of such a
>> > +  ;; character.
>> > +  (when (>= (move-to-column startcol (if fill t 'coerce)) startcol)
>> >      (delete-region (point)
>> >  		   (progn (move-to-column endcol 'coerce)
>> >  			  (point)))))
>> 
>> This patch gives similar result of kill-rectangle.
>> In the example above, I want all '4' characters moved to same column.
>
> How can that be done, when the first character takes 2 or more
> columns?  Deleting the first character is IMO wrong, since the other
> lines leave the first character intact.  Adding SPC to other lines is
> also wrong, since delete-rectangle is not supposed to _add_ columns.

I think wide characters may be replaced with SPC like TAB.

>> And TAB characters crossing the end column are not edited correctly
>> with delete-rectangle if indent-tabs-mode is on.
>> 
>> 012345678
>> 	8(TAB at head)
>> 012345678
>> 
>> The text above is edited to the text below.
>> 45678
>> 	8(TAB at head)
>> 45678
>> 
>> If indent-tabs-mode is off, the result is the text below.
>> 45678
>>     8(four SPCs)
>> 45678
>
> This is a separate issue with the original code.  It also happens with
> kill-rectangle, btw.  We could fix it by temporarily binding
> indent-tabs-mode to nil inside these commands -- would that be
> acceptable?  The result will be that the killed rectangle includes
> spaces, not the leading TAB.

I prefer that the killed rectangle has same column for each line.
If TAB is included when yanking, the current column affects the width of
the yanked string for each line.

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Eli Zaretskii]

> From: awrhygty@outlook.com
> Cc: 67925@debbugs.gnu.org
> Date: Thu, 21 Dec 2023 23:26:05 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> This patch gives similar result of kill-rectangle.
> >> In the example above, I want all '4' characters moved to same column.
> >
> > How can that be done, when the first character takes 2 or more
> > columns?  Deleting the first character is IMO wrong, since the other
> > lines leave the first character intact.  Adding SPC to other lines is
> > also wrong, since delete-rectangle is not supposed to _add_ columns.
> 
> I think wide characters may be replaced with SPC like TAB.

I don't think I agree.  Let's see what others think Stefan, Juri,
Stefan, any opinions?  Does anyone else have an opinion on this?

> >> And TAB characters crossing the end column are not edited correctly
> >> with delete-rectangle if indent-tabs-mode is on.
> >> 
> >> 012345678
> >> 	8(TAB at head)
> >> 012345678
> >> 
> >> The text above is edited to the text below.
> >> 45678
> >> 	8(TAB at head)
> >> 45678
> >> 
> >> If indent-tabs-mode is off, the result is the text below.
> >> 45678
> >>     8(four SPCs)
> >> 45678
> >
> > This is a separate issue with the original code.  It also happens with
> > kill-rectangle, btw.  We could fix it by temporarily binding
> > indent-tabs-mode to nil inside these commands -- would that be
> > acceptable?  The result will be that the killed rectangle includes
> > spaces, not the leading TAB.
> 
> I prefer that the killed rectangle has same column for each line.
> If TAB is included when yanking, the current column affects the width of
> the yanked string for each line.

Again, does anyone else have an opinion here?  I tend to think that we
should bind indent-tabs-mode to nil inside those functions.

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> I think wide characters may be replaced with SPC like TAB.
> I don't think I agree.   Let's see what others think Stefan, Juri,
> Stefan, any opinions?  Does anyone else have an opinion on this?

I think in those circumstances, all options suck, and I suspect that the
preferred behavior will depend on not only who you ask, but also what
the specific case looks like :-(

IME inserting SPCs is wrong when the text you started from doesn't
include any whitespace at all, for example.

And not inserting SPC tends to be equally wrong when alignment needs to
be preserved.

There's no way to win, unless we can find a way to let the user control
the behavior, which seems difficult to do without making the UI overlay complex.


        Stefan

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Juri Linkov]

>> >> This patch gives similar result of kill-rectangle.
>> >> In the example above, I want all '4' characters moved to same column.
>> >
>> > How can that be done, when the first character takes 2 or more
>> > columns?  Deleting the first character is IMO wrong, since the other
>> > lines leave the first character intact.  Adding SPC to other lines is
>> > also wrong, since delete-rectangle is not supposed to _add_ columns.
>>
>> I think wide characters may be replaced with SPC like TAB.
>
> I don't think I agree.  Let's see what others think Stefan, Juri,
> Stefan, any opinions?  Does anyone else have an opinion on this?

Does the same problem exist for deleting rectangles in texts
with a variable-pitch font?  If you draw a vertical line
it will cross a lot of characters in the middle.

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: awrhygty@outlook.com,  Stefan Monnier <monnier@iro.umontreal.ca>,
>   Stefan Kangas <stefankangas@gmail.com>,  67925@debbugs.gnu.org
> Date: Fri, 22 Dec 2023 09:56:20 +0200
> 
> >> >> This patch gives similar result of kill-rectangle.
> >> >> In the example above, I want all '4' characters moved to same column.
> >> >
> >> > How can that be done, when the first character takes 2 or more
> >> > columns?  Deleting the first character is IMO wrong, since the other
> >> > lines leave the first character intact.  Adding SPC to other lines is
> >> > also wrong, since delete-rectangle is not supposed to _add_ columns.
> >>
> >> I think wide characters may be replaced with SPC like TAB.
> >
> > I don't think I agree.  Let's see what others think Stefan, Juri,
> > Stefan, any opinions?  Does anyone else have an opinion on this?
> 
> Does the same problem exist for deleting rectangles in texts
> with a variable-pitch font?  If you draw a vertical line
> it will cross a lot of characters in the middle.

No, since columns still count correctly, as long as Emacs considers
all characters to be of the same single-column width.  IOW, the
rectangle commands work by columns, not by pixel-coordinates.

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Does the same problem exist for deleting rectangles in texts
> with a variable-pitch font?

No, with variable pitch fonts there is also a problem but it's
a different one.  Basically the rectangle commands operate by pretending
your font is monospaced.  You can see it with the rectangle highlighting
of `C-x SPC` where the "rectangle" won't be very rectangular in the
presence of variable pitch fonts.

For such cases, it's not even clear what The Right Thing™ should be.


        Stefan

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

>> Does the same problem exist for deleting rectangles in texts
>> with a variable-pitch font?
>
> No, with variable pitch fonts there is also a problem but it's
> a different one.  Basically the rectangle commands operate by pretending
> your font is monospaced.  You can see it with the rectangle highlighting
> of `C-x SPC` where the "rectangle" won't be very rectangular in the
> presence of variable pitch fonts.
>
> For such cases, it's not even clear what The Right Thing™ should be.

I tried "Block Area Selection" in LibreOffice with variable pitch fonts,
and the vertical lines are not straight:


[-- Attachment #2: rect_libre.png --]
[-- Type: image/png, Size: 74416 bytes --]

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]


So maybe it's impossible to draw straight rectangle boundaries.

OTOH, with monospaced fonts LibreOffice selects such Block Area
on the reported text:


[-- Attachment #4: mono_libre.png --]
[-- Type: image/png, Size: 6229 bytes --]

[-- Attachment #5: Type: text/plain, Size: 72 bytes --]


and DEL deletes the selected text.  So maybe Emacs should do the same.

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  awrhygty@outlook.com,  Stefan Kangas
>  <stefankangas@gmail.com>,  67925@debbugs.gnu.org
> Date: Sat, 23 Dec 2023 19:30:03 +0200
> 
> OTOH, with monospaced fonts LibreOffice selects such Block Area
> on the reported text:
> 
> 
> and DEL deletes the selected text.  So maybe Emacs should do the same.

The patch I posted in

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67925#8

is supposed to do precisely that (and does it at least in this simple
example).

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Juri Linkov]

>> OTOH, with monospaced fonts LibreOffice selects such Block Area
>> on the reported text:
>> 
>> and DEL deletes the selected text.  So maybe Emacs should do the same.
>
> The patch I posted in
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67925#8
>
> is supposed to do precisely that (and does it at least in this simple
> example).

I confirm this, so probably it's impossible to do anything better than that.

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

>>> OTOH, with monospaced fonts LibreOffice selects such Block Area
>>> on the reported text:
>>>
>>> and DEL deletes the selected text.  So maybe Emacs should do the same.
>>
>> The patch I posted in
>>
>>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67925#8
>>
>> is supposed to do precisely that (and does it at least in this simple
>> example).
>
> I confirm this, so probably it's impossible to do anything better than that.

Doing as well as LibreOffice is probably already not bad.

Perhaps we should add a comment pointing to this discussion, to explain
why we have chosen this particular heuristic.

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 24 Dec 2023 06:52:13 -0800
> Cc: monnier@iro.umontreal.ca, awrhygty@outlook.com, 67925@debbugs.gnu.org
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> >>> OTOH, with monospaced fonts LibreOffice selects such Block Area
> >>> on the reported text:
> >>>
> >>> and DEL deletes the selected text.  So maybe Emacs should do the same.
> >>
> >> The patch I posted in
> >>
> >>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67925#8
> >>
> >> is supposed to do precisely that (and does it at least in this simple
> >> example).
> >
> > I confirm this, so probably it's impossible to do anything better than that.
> 
> Doing as well as LibreOffice is probably already not bad.
> 
> Perhaps we should add a comment pointing to this discussion, to explain
> why we have chosen this particular heuristic.

Thanks.  Since it sounds like everyone agreed with the solution I
proposed, I have now installed that on the master branch, and I'm
therefore closing this bug.

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[awrhygty]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Sun, 24 Dec 2023 06:52:13 -0800
>> Cc: monnier@iro.umontreal.ca, awrhygty@outlook.com, 67925@debbugs.gnu.org
>> 
>> Juri Linkov <juri@linkov.net> writes:
>> 
>> >>> OTOH, with monospaced fonts LibreOffice selects such Block Area
>> >>> on the reported text:
>> >>>
>> >>> and DEL deletes the selected text.  So maybe Emacs should do the same.
>> >>
>> >> The patch I posted in
>> >>
>> >>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67925#8
>> >>
>> >> is supposed to do precisely that (and does it at least in this simple
>> >> example).
>> >
>> > I confirm this, so probably it's impossible to do anything better
>> > than that.
>> 
>> Doing as well as LibreOffice is probably already not bad.
>> 
>> Perhaps we should add a comment pointing to this discussion, to explain
>> why we have chosen this particular heuristic.
>
> Thanks.  Since it sounds like everyone agreed with the solution I
> proposed, I have now installed that on the master branch, and I'm
> therefore closing this bug.

The preview of 'C-x r t'(string-rectangle) seems different from the
result.

Before:
12345
一二5
12345

Preview:
1x2345
 x 二5
1x2345

Result:
1x2345
一x二5
1x2345

bug#67925: 29.1; delete-rectangle fails on multi-column characters

[Eli Zaretskii]

> From: awrhygty@outlook.com
> Cc: Stefan Kangas <stefankangas@gmail.com>,  juri@linkov.net,
>   monnier@iro.umontreal.ca,  67925-done@debbugs.gnu.org
> Date: Thu, 04 Jan 2024 04:00:49 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Kangas <stefankangas@gmail.com>
> >> Date: Sun, 24 Dec 2023 06:52:13 -0800
> >> Cc: monnier@iro.umontreal.ca, awrhygty@outlook.com, 67925@debbugs.gnu.org
> >> 
> >> Juri Linkov <juri@linkov.net> writes:
> >> 
> >> >>> OTOH, with monospaced fonts LibreOffice selects such Block Area
> >> >>> on the reported text:
> >> >>>
> >> >>> and DEL deletes the selected text.  So maybe Emacs should do the same.
> >> >>
> >> >> The patch I posted in
> >> >>
> >> >>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67925#8
> >> >>
> >> >> is supposed to do precisely that (and does it at least in this simple
> >> >> example).
> >> >
> >> > I confirm this, so probably it's impossible to do anything better
> >> > than that.
> >> 
> >> Doing as well as LibreOffice is probably already not bad.
> >> 
> >> Perhaps we should add a comment pointing to this discussion, to explain
> >> why we have chosen this particular heuristic.
> >
> > Thanks.  Since it sounds like everyone agreed with the solution I
> > proposed, I have now installed that on the master branch, and I'm
> > therefore closing this bug.
> 
> The preview of 'C-x r t'(string-rectangle) seems different from the
> result.
> 
> Before:
> 12345
> 一二5
> 12345
> 
> Preview:
> 1x2345
>  x 二5
> 1x2345
> 
> Result:
> 1x2345
> 一x二5
> 1x2345

I don't see this as a significant problem, and don't think we should
waste time and efforts on trying to "fix" it.  The current preview
doesn't look less correct or more incorrect than what we had before
the changes.

Sorry, I don't want to try to change anything due to this new issue.