bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12723: 24.2; Improvement: changing text rectangle kill/past and its


From: Eli Zaretskii
Subject: bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
Date: Thu, 25 Oct 2012 21:43:19 +0200

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: ma.jiehong@gmail.com, 12723@debbugs.gnu.org
> Date: Thu, 25 Oct 2012 14:33:31 -0400
> 
> > 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.
> 
> There are several easy ways out:
> - Let the user turn off highlighting.
> - Let the user not look at the highlighting.
> - Don't highlight if the text contains a mix of L2R and R2L (or just
>   highlight it in a simpler way that only shows the position of the
>   mark).

How about this additional alternative: overlay the marked rectangle
with an overlay (pun intended) which has a 'display' property, a
string that's a copy of the marked text with a newline appended to
each (partial) line?  This display string will then look correctly
with or without bidirectional text, and it will also show the user how
the text will look if yanked into an empty buffer.  The only problem
is that sometimes some of the marked text will show to the left or
right of the overlay, but that's tolerable, I think, and we could make
the surrounding text pale so it's almost invisible.

> I think it should highlight the text actually selected, which doesn't
> give us much leeway.

The above suggestion fulfills that requirement.

> All I know is that the rectangle highlighting won't need complex
> bidi-aware code.  At most it will have to detect that there's bidi
> involved and fallback to another highlighting method.

A method that changes depending on the scripts involved would be
confusing, I think.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]