Bug 91041

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?

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.  

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? :)

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.

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).

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.

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
     }
   }
+  }
 }
 

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);
 }
 

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.

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.

Regressed in 3.5.5

Hi Leo, in what way? triple-click still includes new-line.

Works for me in my KDE /trunk checkout like expected.