Community
Participate
Working Groups
This is a common and convenient behavior for text editors/IDEs which is missing. Would be nice to have it. Switching to keyboard and doing "shift+arrow down" seems like a lot more effort for achieving the same effect.
Some people like this functionality, and some don't. In addition, whether or not this makes sense is at least partially related to the domain of the editor (for example, "select-a-line" makes sense for a Java editor, but "select-a- sentance" or "select-a-paragraph" might be more appropriate for a plain text editor). There are two possible places where it could show up. One is in the native widgets, in which case, if it happens at all it will be as a side-effect of the normal functioning of the native widget. The other possibility is in the StyledText code. StyledText is a custom widget whose behavior is defined by the needs of the Eclipse UI team. It *is* platform neutral, so if triple-click were to be added, it would show up on all platforms. Note that, few (none?) of the operating systems SWT is implemented on provide triple-click notification, so this would have to be done by detecting the event times in the StyledText code. Moving to the UI team for consideration.
Defer for consideration after 2.0. Semantics based selection expansion may be preferable even in code (see Edit / Expand Selection).
Reopen to move
Move to text
*** Bug 21310 has been marked as a duplicate of this bug. ***
> Some people like this functionality, and some don't. Then make it optional, but *please* make it. Triple-click has been an important part of code editors (starting on the Mac, but soon spreading everywhere) for over ten years. Make sure you also implement triple-click-and-drag (which selects and deselects entire lines as the cursor is dragged over them). By the way, double-click-and-drag is also unimplemented, which is unfortunate. See http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-205.html for the thoughts of people who have thought about this a lot (they agree that in different contexts, triple-click may mean "select sentence" or "select paragraph").
1. Paragraph selection only makes sense for editors that wrap. Otherwise, there are only lines. 2. If you do happen to implement selection drag and drop, please make it optional. It's an invention of the devil.
> If you do happen to implement selection drag and drop, please make it optional. It's an invention of the devil. Absolutely! Let me be clear: double-click-and-drag is when you click down-up- down, then immediately start to drag the cursor. It expands the selection area, selecting entire words (*not* merely individual characters) as those words come under the cursor. It's akin to shift-control-rightarrow in Word and other editors. Triple-click-and-drag expands and shrinks the selection line by line. Selection drag and drop is stupid and whoever invented it should be dragged over broken glass and dropped in a spiked pit.
This bug is closely related to bug 22880, which details how to implement this click-hold and multiple-click behavior. A specific complaint about how double-click and drag (often referred to as 1.5 click: mouse-down, mouse-up, mouse-down, and hold while you drag is not quite 2 full clicks!) should work can be found in bug 21336. Regarding these questions, it should be noted that on almost all editors, on almost all platforms, double-clicking selects a word and double-clicking and then dragging (1.5 clicks and a drag) extends the selection word-wise. Triple- click behavior is less uniform. While it may be annoying to some that triple-clicking doesn't select a line (and I agree that it should!), the behavior on 1.5-click and drag is truly asinine: If you 1.5-click on a word and then move the mouse, the selection extends by characters, not by words. Then, on mouseup, the selection reverts back to only include the originally clicked-on word. This is doubly unexpected and bad behavior, and should be fixed in the same set of fixes that defines triple- click behavior.
For the double-click-and-drag issue, see (and vote for!) bug 33193
*** Bug 51725 has been marked as a duplicate of this bug. ***
Created attachment 14386 [details] patch for double click, hold and drag and triple click I have attached a small patch which allows you to: - double click, hold and drag to select multiple words - triple click to select lines the triple click stuff works only on MacOSX (carbon). The double click might work on other OS' too, but I don't have access to other boxes. The patch is against version R3_0. Basically I made these changes: 1. for triple click: org.eclipse.swt: I introduced a 'int click_count' member to Event.java and MouseEvent.java. This is set from inside of sendMouseEvent() in Control.java and works with any number of mouse clicks org.eclipse.jface.text: Added a new class ITextTripleClickStrategy, which adds one method tripleClicked() In TextViewer$TextDoubleClickStrategyConnector I added fClickCount and mouseDown(). fClickCount remebers the click count of the last mouseDown In mouseUp() if the fClickCount is 3, I send a tripleClicked() if the Strategy is a ITextTripleClickStrategy DefaultTextDoubleClickStrategy implements ITextTripleClickStrategy and adds tripleClicked() method org.eclipse.jdt.ui: JavaDoubleClickSelector also implements ITextTripleClickStrategy and adds tripleClicked() method 2. for double click n drag support (this should work on all platforms) org.eclipse.jface.text.DefaultTextDoubleClickStrategy and org.eclipse.jdt.ui.JavaDoubleClickSelector Changed the doubleClicked() method to use the start AND end point of the mouse selection to calculate the resulting selection. JavaStringDoubleClickSelector calls super instead of selectWord() directly Comments: - The feedback during the mouse drag is still wrong. - Shift-Clicking doesn't remember that the original click was a double/triple click (always selects characters) - To make this work on Win* and other OS', basically what I do here in SWT/carbon: org.eclipse.swt.widgets.Control.sendMouseEvent() (getting the click count and store it into the Event) has to be duplicated. Everything else should work from there.
Created attachment 14387 [details] zip file for double/triple click patch trying to submit again, last attachment was displayed as text...
Thanks for the patch. We will look at this when we attack the corresponding 3.1 plan item: - interaction (mouse, keyboard) * selection modes (line selection, word selection)
Handling of double/triple clicks is something that a lot of editors get wrong in a variety of subtle ways. Here are the details of what I consider to be the "correct" behavior. 1. Double-click should select the clicked work on the second mouse press (*not* release). It should *not* select spaces or punctuation marks to either side of the word. Double-clicking on a space or punctuation mark should select only that character. 2. Double-click-drag should select a sequence of whole words. 3. Triple-click should select the clicked line, *including* the carriage return at the end of it. (Swing messes up on that one.) Again, selection should occur on mouse down, not mouse up. It should not matter where in the line you click. In particular, triple-clicking to the right of the last character should still select the line. (IDEA 3.x messed up on that one, but they fixed it in 4.0.) 4. Triple-click-drag should select a series of whole lines, again including the carriage return at the end of the last line. (jEdit, which otherwise gets everything right, messes up on that last carriage return.)
*** Bug 82398 has been marked as a duplicate of this bug. ***
*** Bug 28733 has been marked as a duplicate of this bug. ***
Created attachment 22577 [details] patch to add support for triple-clicking This patch adds support for triple-clicking (or as many clicks as you like) to select an entire line. I have taken a simliar approach to Marc Guenther's patch, only this one doesn't require any swt changes and is limited to just one plugin - org.eclipse.jface.text. This patch also changes the double- and triple-click to select on the mouse down event, rather than the mouse up event. This behaviour is consistent with the way most text editors work (I tried several editors on both Mac OS and Windows and they all selected on mouse-down). If people prefer the current Eclipse way, perhaps this could be made into a preference option.
Who do we have to bribe to get this feature implemented? ;) Looks like this bug has been open for over 3 years now. Is there any chance of getting something like an extension point in place for 3.1? Please throw us poor folks a bone!
Chris, I'm sure the Text team will look at your patch after 3.1 is out. I guess it came a bit too late for inclusion in 3.1 since we were already in a stabilization lockdown phase by that time. I've tried your patch, and I discovered that it does not implement several items of Peter's comment 15 "correctly" (IMO, that list shows the desired behavior, except for double-clicking a tab or a space, which should select all adjacent whitespace except for line delimiters). 1. Double-clicking on a tab before a word as in System.out.println(); selects the tab and the next word. Should only select the tab(s) before the word. 2. Double-click-and-hold does not expand the selection word-wise, but character-wise. 3. Triple-click should select the clicked line, *including* the line delimiter(s) at the end of it. The patch misses the line delimiter. 4. See 2. and 3.
Hi Markus, > Chris, I'm sure the Text team will look at your patch after 3.1 is out. Sorry to say, but the same I heard last year about my patch, it will be worked on after 3.0 comes out. But unfortunately that never happened. So who do we need to bribe again? :-) btw, I agree with the desired behauvoir you describe, espacially about double clicking on white space. Chris, are you interested in implementing the changes Markus described? Otherwise I might give it a try.
I agree that Peter's way (comment 15) is the "right way." It should be the default behaviour for a generic text editor, with the ability to override/customize behaviour for different kinds of editors. My patch was a bit too simplistic. Marc, feel free to tackle this... :)
>> Chris, I'm sure the Text team will look at your patch after 3.1 is out. >Sorry to say, but the same I heard last year about my patch, it will be worked >on after 3.0 comes out. >But unfortunately that never happened. So who do we need to bribe again? :-) Please read comment 14 again ;-) The mentioned item wasn't on the committed items list and there was unfortunately not enough time to attack it, that's why we did not look at these patches yet. There were already several comments in that PR what should/will happen upon double- and tripple-click: this is up to each viewer / editor e.g. Java defines its own double-click strategy and hence changes/whishes regarding the functioning of double- and tripple-click in individual editors should be placed there. Chris, one thing that I didn't like in your patch is the 'multi'. I suggest to keep it to "Tripple" otherwise we should also add support registering of more than one multi click strategy.
Note that we are still waiting for an answer whether StyleText will provide tripple-click mouse events (see bug 23614). I've just pinged them again in the bug.
> Chris, one thing that I didn't like in your patch is the 'multi'. I suggest to > keep it to "Tripple" otherwise we should also add support registering of more > than one multi click strategy. Actually this was deliberate. It's very annoying to have to do precisely 3 clicks to select a line. What most editors do is treat 3 or more clicks the same as a triple-click, but they definitely don't limit you to exactly 3 clicks. You're probably right though in that no one's going to want to register more than one multi-click strategy (ie if 3 clicks do this, if 4 clicks do this, etc). Calling it "Triple" rather "Multi" is fine as long as it still works with >3 clicks.
*** Bug 107974 has been marked as a duplicate of this bug. ***
Just FYI, as a pseudo-workaround until this feature gets implemented - if you're in a Java editor and have the line number display turned on, clicking on the line number selects the line. Unfortunately it doesn't appear to get the newline, though, grrr. At least not in Eclipse 3.2M4. But that's another bug.
see bug 5138, comment 16 for a patch for triple click on MacOSX and double click and drag
Marc, I suggest to add the SWT portion of the tripple-click patch/comments to bug 23614.
*** Bug 143724 has been marked as a duplicate of this bug. ***
Now that the 3.3 design phase is here, I'm sure I speak for all the voters for this bug and tons of other Eclipse users with a Mac background when I say this really needs to be addressed. There are 27 votes for this bug, but far fewer votes for 23614 which is blocking it. Vote for the blocker, too! And all you lurkers out there: vote. You know you want your triple-click.
I'm trying to be helpful, so I apologise if this is a mistake. The bug that was blocking this one is marked FIXED now, so if someone was waiting for that to happen before fixing this one, go go go! :)
My old patch ported to 3.2 is available here: http://www.biffy-berlin.de/marc/doubleTripleClick_patch_320.zip binaries are here: http://www.biffy-berlin.de/marc/doubleTripleClick_jars_320.zip Marc
And here's my old patch ported to 3.2.2: http://www.biffy-berlin.de/marc/doubleTripleClick_patch_322.zip
In case this is being held up by my negative comments in comment #1, I don't have a problem with this going into 3.3. If there are API changes, it still needs a request on the pmc mailing list.
It's there since a few minutes :-)
Ah, Dani, you know how slow I am. ;-) +1 to the API changes.
Fixed in HEAD. Available in builds > N20070318-0010. Per default triple-click will select the line using the new LineSelectionTextTripleClickStrategy. Clients can override this via SourceViewerConfiguration.getTripleClickStrategy(...). NOTE: currently triple-click only works if text drag and drop is disabled, see bug 177927 for details.
Verified in I20070320-0010. I've added bug 178208 and bug 178209 for subtleties from comment 15, and bug 178210 for comment 20.
Making single-line selection on triple-click worked just fine but it turns out that triple-click + mouse move to select multiple lines is hard to do smooth from outside StyledText, see discussions in bug 138579. After discussion with SWT we agreed to pull out the flexibility to configure triple-click from outside but instead directly provide single line selection on triple-click and multi line selection on triple-click + mouse move through the StyledText widget. This means the following new APIs got removed again for M6: ITextTripleClickStrategy ITextViewerExtension7.setTextTripleClickStrategy(...) LineSelectionTextTripleClickStrategy SourceViewerConfiguration.getTripleClickStrategy(...) For M6 I left internal code in place so that at least single line selection on triple-click works.
Moving to SWT to provide this feature for 3.3.
Dani, in StyledText - in our initial design - if you disable double click (StytedText#setDoubleClickEnable(false)) it will disable triple-click too. Is that okay ?
>Dani, in StyledText - in our initial design - if you disable double click >(StytedText#setDoubleClickEnable(false)) it will disable triple-click too. >Is that okay ? Yes, this is fine. In order to make sure other clients learn about this it might be a good idea to deprecate that method and add a new one, e.g. setSelectionOn[Mouse]Click(boolean).
fixed in HEAD > 20070326 Dani, StytedText#setDoubleClickEnable(false) - also disables triple click. In the future we can decide to deprecate this API and add new ones with better names (right now due the API freeze I can not change anything).
Thanks. For the next I-build I removed the temporary triple-click code that I added for M6 and fixed bug 5138 which means text viewers now use StytedText#setDoubleClickEnable(true). Filed bug 179450 to track the API deprecation.
Sorry, I have to reopen this bug. Either SWT forgot to submit to I20070327-0800 or the feature does not work.
OK, I now downloaded and verified in N20070328-0010 where it works. It would really be good if things that are marked with "fixed in HEAD > 20070326" would be available in the upcoming I-build (or at least a statement that it will not be) since most up-stream clients test/sit on the I-builds and not N-builds.
Verified in N20070328-0010.
What about quadruple click?
Just don't click 13 times in a row while chanting "Bloody Mary"... I can't say exactly what happens but you've seen "The Ring", right?
This bug report is tracking triple click.
