Bug 91041 - triple-click should select trailing newline
Summary: triple-click should select trailing newline
Status: RESOLVED WORKSFORME
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Anders Lund
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-10 05:29 UTC by John Firebaugh
Modified: 2007-11-08 19:09 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Firebaugh 2004-10-10 05:29:08 UTC
Version:           unknown (using KDE 3.3.89 (CVS >= 20040820), compiled sources)
Compiler:          gcc version 3.3.4 (Debian 1:3.3.4-13)
OS:                Linux (i686) release 2.6.7-1-k7

Kate has good triple click behavior except for the fact that it does not select the trailing newline when selecting the line on the initial triple click or when extending the selection line by line by triple clicking and dragging. Since what you are trying to do is select the whole line for deletion or copying, it should select the newline as well.
Comment 1 Anders Lund 2004-10-10 22:51:07 UTC
None of the editors I have tried so far has that behavior: kmail composer, nano, kword. I'm told that emacs and vi does too, but under konsole which also have that behavior it's probably inherited.

We shouldn't of cause be bound by tradition, but when the behavior was implemented, i had a standard fro kde apps handy.

Comments, anyone?
Comment 2 Alex V. Koval 2004-10-14 21:55:30 UTC
I think it _could_ be added. On 2-clicks we have line selected in Kate, on
3 clicks line+LineFeed must be.

Please compare:


newline 3x? | program
-------------------
+           | xemacs
-           | kate
-           | kmail
-           | kword
+           | vim (console based)
+           | gvim (X)
+           | scite (X)
-           | mozilla
-           | bluefish

What I mean is that, all of programs which support 2 clicks, do _nothing_ on 3-clicks. Of course if would be very nice if 3-clicks combination will be supported.  

Comment 3 Dominik Haumann 2004-10-14 22:33:53 UTC
As a sidenote: IF you already use the mouse to select a line there is still the option to just click on the left vertical bar (code folding, line numbers, markers bar). You can select lines including newLines. This way we even support both! cool, right? :)
Comment 4 Anders Lund 2004-10-14 22:48:56 UTC
I don't know what "2-clicks" or 3-clicks" is.
Kate have this behaviour: if you doubleclick, it selects the word you click, if you triple-click it selects all text on the line.
I don't think we should change that, if you want to delete a line, press c-k, to select including the following newline with the mouse, do as dominik suggests - drag in the icon bar.
Comment 5 John Firebaugh 2004-10-15 03:39:09 UTC
Please reconsider. I'll be a bit more explicit as to why it's the superior behavior.

The most common reasons why you need to select a line seem to me to be the following: to copy the line and paste it in another location, to cut the line in order to move it somewhere else, or to delete the line. In all of these cases, the vast majority of the time you want to include the corresponding newline in the action. When copying it to another document you want the copy to land on its own line, when moving it you want to move the entire line, and when deleting the line you want the same behavior as Ctrl-K. All of these point to the fact that the best behavior is to select the newline. (The the user in comment #2 seems to agree.)

This is how text controls on the Mac behave, how the Konsole behaves, and how xemacs, gvim, and Nedit behave.

There is one exception to this behavior -- if the line has been wrapped, only the text of the current virtual line should be selected. (http://lists.kde.org/?l=kde-usability&m=108010991610873&w=2) However, Kate doesn't currently implement this behavior anyway.

Dragging in the icon bar is not as good a solution because the icon bar is a very small target, especially compared to the target area of a triple click (the entire line).
Comment 6 Anders Lund 2004-10-15 10:57:42 UTC
Ok, I couldn't get anyone to say their editor had that behavior the other day when i asked around on irc.
I do appreciate the reasoning, so I'll change it then.
Comment 7 Anders Lund 2004-10-15 12:54:44 UTC
CVS commit by alund: 

Make tripleclick select the bol of the below line.
Investigation shows that this was the original behavior of the feature, changed by me to fix #49999 in november 2002.
Later changes to kateview means that the behavior described by #49999 will not appear again, so here you go :)
Can someone fix this in HEAD, as I have changes in katedocument.cpp that are not ready for comitting?
CCMAIL: 91041-done@bugs.kde.org


  M +44 -21    katedocument.cpp   1.734.2.9


--- kdelibs/kate/part/katedocument.cpp  #1.734.2.8:1.734.2.9
@@ -3277,5 +3277,5 @@ void KateDocument::selectLine( const Kat
     clearSelection ();
 
-  setSelection (cursor.line(), 0, cursor.line()/*+1, 0*/, m_buffer->plainLine(cursor.line())->length() );
+  setSelection (cursor.line(), 0, cursor.line()+1, 0 );
 }
 
@@ -4343,6 +4343,28 @@ void KateDocument::slotModifiedOnDisk( K
     m_isasking = 1;
 
-    int exitval = ( v && v->hasFocus() ? 0 : -1 );
+    if ( m_modOnHdReason == 3 ) // deleted
+    {
+      switch ( KMessageBox::warningYesNoCancel( widget(),
+               reasonedMOHString() + "\n\n" + i18n("What do you want to do?"),
+               i18n("File Was Deleted on Disk"),
+               i18n("&Save As..."), i18n("&Ignore Changes")) )
+      {
+        case KMessageBox::Yes: // "save file"
+          m_modOnHd = false; // trick save() to not ask again
+          emit modifiedOnDisc( this, false, 0 );
+          saveAs();
+          m_isasking = 0;
+          break;
 
+          case KMessageBox::No:  // "ignore changes"
+            m_modOnHd = false;
+            emit modifiedOnDisc( this, false, 0 );
+            m_isasking = 0;
+            break;
+
+            default:               // cancel: ignore next focus event
+              m_isasking = -1;
+      }
+    } else {
     switch ( KMessageBox::warningYesNoCancel( widget(),
                 reasonedMOHString() + "\n\n" + i18n("What do you want to do?"),
@@ -4367,4 +4389,5 @@ void KateDocument::slotModifiedOnDisk( K
     }
   }
+  }
 }
 


Comment 8 Dominik Haumann 2004-10-15 22:20:06 UTC
CVS commit by dhaumann: 

foreport anders' fix for bug #91041: triple click includes newLine.
CCMAIL: 91041@bugs.kde.org


  M +1 -1      katedocument.cpp   1.760


--- kdelibs/kate/part/katedocument.cpp  #1.759:1.760
@@ -3338,5 +3338,5 @@ void KateDocument::selectLine( const Kat
     clearSelection ();
 
-  setSelection (cursor.line(), 0, cursor.line()/*+1, 0*/, m_buffer->plainLine(cursor.line())->length() );
+  setSelection (cursor.line(), 0, cursor.line()+1, 0);
 }
 


Comment 9 Hamish Rodda 2004-10-16 02:42:11 UTC
I agree this fix, but the exception that John mentioned for dynamic wrapping is IMHO invalid, as kate doesn't have the concept of a paragraph (which is what the exception refers to); the content (ie, non-rich text) also lacks the concept of a paragraph.  The wrapping is only for the viewing convenience of the user.  Thus, the current behaviour is correct.
Comment 10 John Firebaugh 2004-10-16 07:31:10 UTC
Well, I don't care as much about that point, but I disagree. I don't see any difference between dynamic wrapping and "having a concept of a paragraph". A paragraph is nothing but a really long dynamically wrapped line.
Comment 11 Leo Savernik 2006-10-13 19:58:49 UTC
Regressed in 3.5.5
Comment 12 Dominik Haumann 2006-11-09 18:03:10 UTC
Hi Leo, in what way? triple-click still includes new-line.
Comment 13 Christoph Cullmann 2007-11-08 19:09:07 UTC
Works for me in my KDE /trunk checkout like expected.