bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ma.jiehong@gmail.com,  12723@debbugs.gnu.org
> Date: Thu, 25 Oct 2012 08:28:17 -0400
> 
> >> the highlighting would do the same since the highlighting is there
> >> to make visible what the rectangle operations would/will do.
> > IMHO, this doesn't make sense.  The result will be complete confusion
> > of the user wrt what parts of text are being selected.  You should try
> > that if you don't believe me.
> 
> I'm sure it can be confusing.  Yet, it reflects "which part of the
> text is selected", just as much as the current region highlighting
> does, with the same amount of confusion

The current region is one-dimensional, so the problem there is
smaller, and users of bidirectional scripts are already familiar with
it, because other applications behave in the same way.

> (except that we'd have several such regions, and an expectation that
> the combination should look rectangular).

Exactly.  Note that, depending on the characters present in each line,
there could be up to 3 distinct marked/unmarked portions inside the
rectangle on every line that has some part of it belonging to the
rectangle.

> I'm really not worried, tho: in those cases where it's really confusing,
> people probably don't use rectangle operations anyway (after all, if the
> highlighting is confusing yet reflects what's going to happen, it must
> be pretty difficult for the user to figure out in her head (i.e. without
> the highlighting help) what's going to happen).

It's one thing to leave the rectangle to the user's imagination and
mental models; it's quite another to actually show that to her.  It's
quite possible the users today don't even bother looking what's
between the two corners of the region.  With it highlighted, they
don't have a chance.

> Really, this issue is a complete non-issue

I obviously disagree.

> we're talking about reflecting on screen what is about to happen, so
> any problem "on screen" (i.e. in the highlighting) is really due to
> what's actually going to happen, not to

It's not carved in stone that a rectangular region must be highlighted
in the same way as the "normal" region.  We could come up with
something different, that doesn't suffer from the directionality
issues, for example.

> As soon as you write the code to "fix" kill-rectangle, I'm pretty
> sure updating the highlighting correspondingly will be easy.

Not sure who is "you" and what "fix" you have in mind.