* bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
@ 2012-10-24 17:40 Jiehong Ma
2012-10-24 18:59 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Jiehong Ma @ 2012-10-24 17:40 UTC (permalink / raw)
To: 12723
This is actually a kind of improvement I would like to submit here.
We all know how rectangle selections are working with registers. The idea
of having a rectangle selection is great, but the key-bindings to use
it is far from that adjective. In the following, I would like to
present how I think it would be nicer, and also more accessible to
users.
1. Every selection should start, and act the same way, i.e. by using C-SPC.
2. While the selection is active, switch into a rectangular-mode thanks
to a key-binding (I propose C-x r), and visually show it to the user.
(as does the rect-mark package for example).
3. When the rectangular selection is fully chosen by the user, use a
=E2=80=9Cnormal=E2=80=9D function to kill it: C-w, M-w.
4. Give access to this rectangle in the kill-ring directly (no need to
name a register).
5. When the user yank a normal piece of text, act as usual. However, if
the current entry in the buffer is a rectangle, yang it accordingly (
for both C-y, M-y)
Having such a work-flow would make the usage of text-rectangle selection
a piece of cake, since we would only need to remember 1 key-binding to
switch the selection into a rectangle-mode.
Registers could be bind to different key-bindings as well.
Technically, I do not really know how to do that. I thought that it may
be possible to actually keep a kind of pointer into the kill ring,
pointing to a register having a unique name. Maybe it could be simpler.
I can't tell, since my knowledge of elisp is limited.
Jiehong Ma
In GNU Emacs 24.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.4)
of 2012-08-28 on shaun
Windowing system distributor `The X.Org Foundation
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
2012-10-24 17:40 bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring Jiehong Ma
@ 2012-10-24 18:59 ` Stefan Monnier
2012-10-24 21:35 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2012-10-24 18:59 UTC (permalink / raw)
To: Jiehong Ma; +Cc: 12723
> In the following, I would like to present how I think it would be
> nicer, and also more accessible to users.
100% agreement. That's exactly how I want it to work, as well.
More specifically, I'd expect `mark-active' to take a special
`rectangle' value to mean that the current selection is
a rectangular region.
Also, I'd expect the rectangular highlighting to be done by moving the
region-highlighting code to Elisp (using the previously-mentioned
but vaporware before-redisplay-hook).
As for how to store the rectangles on the kill-ring, I haven't really
thought about it yet. We could maybe store them as strings with
a special text-property annotation, or as lists of strings, or as a cons
cell (rectange . STRING). The first option is probably best
compatibility-wise, while the second would be a step in the direction of
supporting general non-contiguous regions.
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
2012-10-24 18:59 ` Stefan Monnier
@ 2012-10-24 21:35 ` Eli Zaretskii
2012-10-25 2:22 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2012-10-24 21:35 UTC (permalink / raw)
To: Stefan Monnier; +Cc: ma.jiehong, 12723
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 24 Oct 2012 14:59:22 -0400
> Cc: 12723@debbugs.gnu.org
>
> Also, I'd expect the rectangular highlighting to be done by moving the
> region-highlighting code to Elisp (using the previously-mentioned
> but vaporware before-redisplay-hook).
How would such a rectangular highlighting behave when some of the text
in the region is R2L and some L2R? Will it select text in visual
order or in logical (buffer) order?
Anyway, doing this kind of stuff in Lisp is not trivial even if we
disregard the bidirectional text issue, because variable-size fonts,
double-width characters, composed characters, display strings, and
other display atrocities complicate the 1:1 relation between buffer
text and what's on the glass. In fact, I had hard time doing that in
C with bidi-aware mouse highlight. And AFAICT, we have no facilities
to access display-related structures from Lisp.
So I'd suggest that if someone wants to work on this, he or she
presents a detailed design first regarding the above complications.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
2012-10-24 21:35 ` Eli Zaretskii
@ 2012-10-25 2:22 ` Stefan Monnier
2012-10-25 3:56 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2012-10-25 2:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ma.jiehong, 12723
> How would such a rectangular highlighting behave when some of the text
> in the region is R2L and some L2R? Will it select text in visual
> order or in logical (buffer) order?
The rectangle operations do not currently pay attention to this (they
work on logical order) and the highlighting would do the same since the
highlighting is there to make visible what the rectangle operations
would/will do.
> Anyway, doing this kind of stuff in Lisp is not trivial even if we
> disregard the bidirectional text issue, because variable-size fonts,
> double-width characters, composed characters, display strings, and
> other display atrocities complicate the 1:1 relation between buffer
> text and what's on the glass.
Similarly, variable-width fonts and stuff would not require more work in
the highlighting than in kill-rectangle.
I'm not saying they're not relevant, but as long as kill-rectangle
doesn't take them into account, the highlighting shouldn't either.
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
2012-10-25 2:22 ` Stefan Monnier
@ 2012-10-25 3:56 ` Eli Zaretskii
2012-10-25 12:28 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2012-10-25 3:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: ma.jiehong, 12723
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ma.jiehong@gmail.com, 12723@debbugs.gnu.org
> Date: Wed, 24 Oct 2012 22:22:20 -0400
>
> > How would such a rectangular highlighting behave when some of the text
> > in the region is R2L and some L2R? Will it select text in visual
> > order or in logical (buffer) order?
>
> The rectangle operations do not currently pay attention to this (they
> work on logical order)
That goes without saying. I was asking how this will be reflected on
the screen.
> 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.
> Similarly, variable-width fonts and stuff would not require more work in
> the highlighting than in kill-rectangle.
> I'm not saying they're not relevant, but as long as kill-rectangle
> doesn't take them into account, the highlighting shouldn't either.
So we have visual-line-mode on by default, but rectangle regions will
disregard that completely and treat continued lines as one line? Why
does this make sense?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
2012-10-25 3:56 ` Eli Zaretskii
@ 2012-10-25 12:28 ` Stefan Monnier
2012-10-25 16:53 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2012-10-25 12:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ma.jiehong, 12723
>> 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 (except that we'd have several such
regions, and an expectation that the combination should look rectangular).
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).
> So we have visual-line-mode on by default, but rectangle regions will
> disregard that completely and treat continued lines as one line? Why
> does this make sense?
Don't know. But that's what we have now and have had for eons. Really,
this issue is a complete non-issue: 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
the highlighting per se. As soon as you write the code to "fix"
kill-rectangle, I'm pretty sure updating the highlighting
correspondingly will be easy.
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
2012-10-25 12:28 ` Stefan Monnier
@ 2012-10-25 16:53 ` Eli Zaretskii
2012-10-25 18:33 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2012-10-25 16:53 UTC (permalink / raw)
To: Stefan Monnier; +Cc: ma.jiehong, 12723
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
2012-10-25 16:53 ` Eli Zaretskii
@ 2012-10-25 18:33 ` Stefan Monnier
2012-10-25 19:43 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2012-10-25 18:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ma.jiehong, 12723
> 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).
>> Really, this issue is a complete non-issue
> I obviously disagree.
Then, let's just say that it's a bridge I'm not willing to cross before
we actually get there.
>> 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.
I think it should highlight the text actually selected, which doesn't
give us much leeway.
> We could come up with something different, that doesn't suffer from
> the directionality issues, for example.
Fine by me. 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.
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring
2012-10-25 18:33 ` Stefan Monnier
@ 2012-10-25 19:43 ` Eli Zaretskii
2012-10-26 1:34 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2012-10-25 19:43 UTC (permalink / raw)
To: Stefan Monnier; +Cc: ma.jiehong, 12723
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-10-26 1:34 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-24 17:40 bug#12723: 24.2; Improvement: changing text rectangle kill/past and its integration with the kill-ring Jiehong Ma
2012-10-24 18:59 ` Stefan Monnier
2012-10-24 21:35 ` Eli Zaretskii
2012-10-25 2:22 ` Stefan Monnier
2012-10-25 3:56 ` Eli Zaretskii
2012-10-25 12:28 ` Stefan Monnier
2012-10-25 16:53 ` Eli Zaretskii
2012-10-25 18:33 ` Stefan Monnier
2012-10-25 19:43 ` Eli Zaretskii
2012-10-26 1:34 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).