Re: rox-edit: Fix for 'x lines selected' message

On Sun, May 03, 2009 at 03:02:49PM +0100, Thomas Leonard wrote:
> 2009/5/2 Bernard Jungen <[email protected]>:
> > On Sat, May 02, 2009 at 12:36:49PM +0100, Thomas Leonard wrote:
> >> 2009/5/1 Bernard Jungen <[email protected]>:
> >> > On Fri, May 01, 2009 at 07:50:41PM +0100, Thomas Leonard wrote:
> >> >> 2009/4/27 Bernard Jungen <[email protected]>:
> >> >> > At http://repo.or.cz/w/rox-edit/bju.git?a=commit;h=202e2b1945b81818685925db4ac1e8943a4b6a42
> >> >>
> >> >> "Number of lines was one too much in some special cases
> >> >> Added separate message for the one-line case + French translation"
> >> >>
> >> >> How can it say one line is selected? If the selection starts and ends
> >> >> on the same line then it displays the number of characters instead.
> >> >> What are the special cases where it gets it wrong?
> >> >
> >> > The code says it all. What happens if the newline is selected too? Same number
> >> > of characters selected? No. Two lines selected (as was printed)? No.
> >> >
> >> > The bug is obvious when you're used to select entire lines.
> >>
> >> Before, if you selected just the newline character, it would say "2
> >> lines selected". Now it says "One line selected". Neither is correct,
> >> I think.
> >
> > As long as we talk about partial lines, it is correct IMO. There's no better
> > message for that case.
> >
> >> Perhaps we should display complete lines and extra characters, e.g.
> >> "One character selected" in that case, or "35 lines plus 5 characters
> >> selected", etc?
> >
> > Perhaps. But IMO, it's not useful to have that much precision. The number of
> > lines gives a rough idea of what is selected, as well as a hint for block
> > operations. Talking of block operations, I should have fixed those too. For
> > instance, indenting a selection of 2 full lines now indents 3 lines, which is
> > obviously incorrect. And here you can't fix it by using character precision!
> 
> If the selection goes from the first visible character on the first
> line up to and including the last visible character on the second
> line, then the selection covers two lines and both get indented.
> 
> If you extend the selection by moving over the newline character
> following it, the selection now ends on the third line, three lines
> are now included in the selection,

No. With the pointer to the far left, still only two are selected.

> and indenting indents all three
> lines.

Which is wrong. I didn't select 3 lines.

> Notice that to create this selection using the mouse you have
> to drag over all three lines.

No. I had to drag over *two* lines, from first to third. That makes two lines,
not three. The newline character you've now selected still belongs to the
previous line. You can't select the newline without pointing at the start of the
next line of course, since the end of ranges here (visually) seem to be
*exclusive*, like it's done in many other editors.

The range between 1 and 10 is 9, not 10.

> So, the current behaviour seems correct to me.

No, it's not.

> The behaviour with the
> changed message is clearly inconsistent with indenting.

But that's why I said it should be fixed too! You want proof that only two lines
are selected in the case above? Delete your selection now. The 3rd line won't
even be touched at all. It's funny that deleting three lines only deletes two,
isn't it?

> As I understand it, you want to defining a selection as ending on the
> line containing the end of the selection, *unless* that's at the start
> of a line in which case pretend it ends on the line before.

No. I don't want to pretend anything. The selection is the selection. It's just
that the cursor at the start of a line means the newline character is selected
too, but without any of the current line characters. Simple. Obvious. Logical.
At least if one pays attention to how selections appear on screen.

> That seems
> pretty confusing to me, and would likely require adding special cases
> all over the code.

I beg to differ. The way selections are interpreted now is inconsistent. You
have three choices:

a) Decide that range selections are done specifying bounds *inclusively*, and
fix how they appear on screen, especially when the cursor is at the start or
end of line;

b) Decide that range selections are done specifying bounds *exclusively* (on
one side), and fix the message and block operations. No changes "all over the
code" required. Probably just the indentation code. That won't be the end of
the world;

c) Change nothing and keep confusing users and having these silly arguments.

What do others think? Does any other developer really use that editor?

B.

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf