Bug 149872 - only consider lines with a least one character selected in line based actions
Summary: only consider lines with a least one character selected in line based actions
Status: RESOLVED WORKSFORME
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-14 22:10 UTC by Maciej Pilichowski
Modified: 2008-12-02 01:09 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
selection (6.72 KB, image/png)
2007-09-14 22:11 UTC, Maciej Pilichowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2007-09-14 22:10:12 UTC
Version:            (using KDE KDE 3.5.7)
Installed from:    SuSE RPMs

Make selection like in the screenshot (cursor is in front of "aaa"). What outcome would you expect? Me -- sorted selection. However kate consider selection as "real selection" plus current row. So the outcome is
aaaa
bbbb
cccc
zzzz

instead of

bbbb
cccc
zzzz
aaaa  <-- row intact
Comment 1 Maciej Pilichowski 2007-09-14 22:11:50 UTC
Created attachment 21627 [details]
selection
Comment 2 Anders Lund 2007-09-15 09:34:50 UTC
Comment on attachment 21627 [details]
selection

Use the correct mime type please
Comment 3 Anders Lund 2007-09-15 09:37:21 UTC
The selection is from the line/column where it starts to the line/column where it ends. If we change that, other things goes wrong, as you can imagine.
Comment 4 Maciej Pilichowski 2007-09-15 11:47:24 UTC
Anders, I used auto detection -- I thought it worked better.

What do you mean by line/column? If (line+column) I agree it is good, but as you can see kate for command line interpret boundaries quite differently.

From (Line+0) to (line+end), so you can see column here is completely ignored.

I use only sorting for command-line so it is hard to me to say how could be solved it generally, but for sorting it could be fixed this way (since only whole rows are taken into account) -- process rows partially or fully selected. "Ignore" rows with no selection. Such behaviour is quite intuitive.
Comment 5 Andreas Pakulat 2007-09-15 12:08:16 UTC
Kate's selection is fine, the thing is that it starts on the first z and ends on the line with the a's. As sorting is line-oriented it can completely ignore the column information all it needs is the line-information so the behaviour you see is completely correct as you selected the a-line by putting the cursor onto it.
Comment 6 Maciej Pilichowski 2007-09-15 12:17:24 UTC
Andreas:
"you selected the a-line by putting the cursor onto it."

You are selecting lines by just putting a cursor there? If yes, Kate now has to selections -- real selection (what is selected for real) and some kind virtual selection (when you place cursor).
IMHO it is bad design -- the selection should mean what it means -- what it is selected. And in a-line there is no selection.

It is quite easy to fix it in intuitive manner, so I think it is better to provide useful feature instead of stretching word meaning.
Comment 7 Thomas Friedrichsmeier 2007-12-14 14:49:59 UTC
Well, this is not a bug, it's designed to work that way, and it works the same way for all line based actions. So I will mark it as a wish, instead, and then we can see, whether it gets any voting.

Yes, there is some room for choice regarding which lines should be included in line based actions. I can see three main approaches:

1) Only consider lines which are *fully* selected
This would probably have the least potential for confusion, but also it would require the user to select much more precisely.

2) Only consider lines with at least one character selected
That's your wish.

3) Only consider lines with at least one character selected and / or the cursor on that line.
The current behavior.
Comment 8 Anders Lund 2007-12-14 20:56:36 UTC
1) The command works as expected if you look at it. I see no reason for 
changing the behaviour.

2) What is 'line based actions'? There is no such group of actions in Kate or 
Katepart that I know of.

For me, this is clearly a WONTFIX. When working on selections, it is up to you 
to make an accurate selection, Kate(Part)s job is to do exactly what it says 
it will ;)
Comment 9 Maciej Pilichowski 2007-12-14 21:58:08 UTC
1) not exactly -- the point of selecting data is to well, select data to do some action, but currently user select one thing and Kate operates on something else (on extension to be clear) -- such behaviour is unwanted (not only in Kate, but in general)
 
>When working on selections, it is up to you 
> to make an accurate selection, Kate(Part)s job is to do exactly what it says 
>  it will ;) 

I selected precisely two lines (for example), and Kate sorts three.

Anders if you are not convinced please answer this question -- when I select two lines:
|aaaaaaaaaaa
bbbbbbbbbb
|ccccccccc

what part of the third line is selected:
1) none
2) one characters
3) several characters
4) entire line



Comment 10 Anders Lund 2007-12-14 22:21:44 UTC
On Friday 14 December 2007, Maciej Pilichowski wrote:
> Anders if you are not convinced please answer this question -- when I select 

two lines:
> |aaaaaaaaaaa
>
> bbbbbbbbbb
>
> |ccccccccc
>
> what part of the third line is selected:
> 1) none
> 2) one characters
> 3) several characters
> 4) entire line


The beginnning of the line is selected, since that is where you put the 
selection end. I don't know the origin of the sort command used in the bug 
report, but likely it takes the selection, does something similar to sort(1) 
without arguments, and replaces the selection with the result, that is the 
common behavior for actions working on the selection.
Comment 11 Maciej Pilichowski 2007-12-15 08:54:34 UTC
> The beginnning of the line is selected, since that is where you put the 
> selection end. 

I had never spot such "object" as the beginning of the line in any text editor, including Kate. There is only "end of the line" (but as the name indicates it belongs to the line it is at the end). I can write another test for it :-)

So in that case the end of the line is selected, but of bbbbb! 
Comment 12 Thomas Friedrichsmeier 2007-12-16 20:20:12 UTC
By "line based actions" I meant actions which work on selections of entire lines. I.e. Indent/Unindent, Join Lines, the sort command, and - well, I'm not even sure, there are any more than that.

But actually, I just tried Indent/Unindent and Join Lines, and in fact those do *not* touch the last line, in the case in question, while "sort" does. So this really is a bit inconsistent.
Comment 13 Maciej Pilichowski 2008-11-25 14:46:04 UTC
Just for the record, it is not only incosistent but it is a bug for real, see the Matthew comment in:
http://bugs.kde.org/show_bug.cgi?id=175735#c19
Comment 14 Matthew Woehlke 2008-11-26 18:35:24 UTC
IMO, from comment #7, 2) is the correct behavior, 3) is wrong. '\n<EOS>' should not be treated as a line, it just means that ALL of the previous line, including the '\n', is selected.

Indentation works correctly, '^' regex matching does not (but that's bug #175735). I'd like to get this out of UNCONFIRMED. Please either describe reproducible steps (i.e. give an example of a "line-based action" that works wrong), or let me know if this can be closed WORKSFORME or REMIND.

Andreas: the way selection works makes sense based on how the code is written, but not behavior-wise; right now we appear to get things right behavior-wise in some cases, but not others. The selection line==x,col==0 should not be treated as including line x (for col!=0, line x should be considered).
Comment 15 Maciej Pilichowski 2008-11-26 19:59:36 UTC
Previously sort from command line caused the problem, but I don't see it any longer at all in Kate4. It was like this

[ccc
bbb
]aaa

sort and the result should be

bbb
ccc
aaa

If there is no sort, or there is and it works --> WORKSFORME.
Comment 16 Matthew Woehlke 2008-12-02 01:09:09 UTC
> If there is no sort, or there is and it works --> WORKSFORME.

I don't see a 'sort', and it otherwise seems to be working. Please re-open with more details if this is still an issue.