Community
Participate
Working Groups
Right clicking in an editor should move the caret on the mouse down to the current mouse position (unless you right click on selected text) so the context menu affects where you clicked. Right now, the context menu operates on where the caret currently is (which could even be off screen!). It is very irritating to do something like right click on a method call and select "Open Declaration" and not get the method you right clicked on.
I believe this is a bug, not an enhancement. It is not correct for the context menu to not affect the point clicked.
Created attachment 3148 [details] Right click fix This patch correctly handles context menus and text selections. It basically works like this: On mouse down: * if the mouse is not over selected text, move the caret * if the mouse is over selected text, leave the selection alone On mouse move: * if the mouse is not over selected text, change pointer to i-beam * if the mouse is over selected text, change pointer to arrow
It strikes me that this is neither a bug, nor an enhancement, but rather a policy issue. I personally find the "right click selects" behavior vastly irritating in the subset of text editors which support it. Having said that, I'm sure that there are many who would find it desirable.In any case, this needs to be considered by the UI and Text teams to decide if this is the behavior they want.
I'm not sure I understand what you mean by "right click selects". Do you mean you: 1) never want the caret to move when you right click, 2) never want the caret to move when there is a selection, or 3) something else? I would strongly disagree with #1 (this is what *I* consider vastly irritating), disagree (but less strongly) on #2, and can't really give an opinion on #3 until I find out what it is :-).
I'm not convinced that this should be the default behavior of the widget or that we should change this behavior. I certainly don't find the behavior as irritating as Ron does, the behavior is not "standard" (e.g., the platform text widget on Windows does not provide the behavior), and the popup menus for the editors in Eclipse are context-sensitive based on the selection, not the caret location. Anyway, I imagine that changing the StyledText widget is not the only way to provide this behavior. Ron, have you tried hooking mouse down/mouse move on the Text Editor to provide the behavior?
Oops, my mistake about the context-sensitive nature of the Java editor. I use F3 a lot vs. the context menu. Anyway, it is kind of annoying if that is your mode of operation. Still, this is pretty particular to the Eclipse editor usage of the StyledText widget. Can you see if a solution on top of StyledText can be provided.
You're right about the fact that the native text widget in Windows doesn't have this behavior. But then, Notepad has a reputation for a reason... :-) While the behavior may not be "platform standard," it does seem to be "text editor standard." With the exception of Notepad, every other text editor on my system moves the caret on a right click when there is no selection, and are nearly evenly split on whether a right click outside an existing selection moves the caret: right click outside existing selection, doesn't remove selection or move caret: WordPad, TextPad, UltraEdit, IDEA click outside existing selection, removes selection, moves caret: Visual C, Visual Basic, Word I prefer the second way (which is what the patch implements), but I wouldn't be surprised to find that many prefer the first way. Either way is considerably better than the current behavior. It comes down to this: something this common in "real" text editors is a strong argument for inclusion in Eclipse's text editor. Besides, it's consistent with the way context menus interact with the rest of the UI (both Eclipse and Windows in general) and is therefore intuitive -- you expect a context menu opened by a mouse click to operate where clicked. Otherwise, what's the point of using the mouse? Ok, I'm stepping down from my soapbox now... As to looking for an alternate solution, are your suggesting a modification to somewhere else in the Eclipse codebase, or a 3rd party plug-in solution? (If it was the latter, perhaps I've persuaded you to reconsider?)
"right click outside existing selection, doesn't remove selection or move caret:" As far as I can see, this *is* the current behavior of the widget, and for the record, *we* like it that way, since it's the way every IDE we've ever built (i.e. VA/ME 1.0, VA/Java, VA/Smalltalk, ...) works. Separate from that however, SWT ought to do whatever the platform widgets do. If native text widgets, used in the canonical way do not move the selection, then SWT should not. However, there is a consistancy argument in favor of Ron's view _at_the_Eclipse_UI_ level: Eclipse implements "right click selects before popping up the menu" behavior in Trees. It would seem that we should do the closest "typical" behavior in the text widgets as well (which is the behavior Ron wants). This is a UI TEAM decision, and as such they were in error to send you back to the SWT team.
Ron, yes I'm suggesting that you try to put the behavior elsewhere in the Eclipse code base (e.g., hook Mouse events on the StyledText widget associated to the TextViewer). Putting the behavior in StyledText is a behavior change that would potentially break someone (e.g., what if someone had a menu option for inserting something at the caret location, then the proposed right click behavior would break them). You should be able to provide the behavior by hooking mouse events and using StyledText API.
The MS UI Guidelines ("Windows User Experience") has this to say about selection in Chapter 6's section on "Mouse Selection": - "Support user selection using either mouse button." - "If the user presses the secondary mouse button to make a selection, display the shortcut menu for the selection when the user releases the mouse button." Although they don't give a concrete example of this particular scenario for text, the chapter does include examples of selecting text, not just other kinds of objects, and they don't mention any exceptions for selecting text. The Mouse Interface Summary in Appendix A backs this up. See: http://msdn.microsoft.com/library/en-us/dnwue/html/ch06c.asp http://msdn.microsoft.com/library/en-us/dnwue/html/appxA.asp So it sounds like MS recommends Ron's preferred mode of operation. However, I have some concerns. 1. My main concern has to do with ease of use. If the normal case is that you want the menu to apply to the current selection, then you now must ensure you pop up the menu over the selection, otherwise it will change the selection. This drastically reduces the size of the target area for the right click action, from the size of the whole editor to the size of the selection (which may be quite small). Fitts's law explains why this is bad (http://www.asktog.com/basics/firstPrinciples.html#fitts's%20law). 2. This may not be the recommended mode on other platforms (I checked the Mac guidelines, but didn't see anything relevant). 3. This may not be everyone's preferred mode of operation (as evidenced by the discussion here, and the disparity between other editors out there). Based on (1), I question whether we should support this at all. If we do decide to support it, then due to (2) and (3), the user should be able to decide which mode they prefer via a preference. StyledText should not be changed to adopt this as its default mode of operation, although support could be added to simplify adopting it where desired. But it's the Text team's final call on whether they want to support this in the text editors, and whether they want to adopt Ron's patch.
McQ: After your comment about doing whatever the platform widgets do, I wonder if we talking about the same thing. It seems you are referring to SWT's text widget, and I'm talking about Eclipse's text editor. I say this because it doesn't make sense for the text editor to "follow platform behavior." If this were to be followed, we would have to remove indent/unindent, scrolling without moving the caret position (Ctrl+Up/Down), and syntax highlighting (among others), because the platform (Windows, anyway) doesn't do those either. For the record, I do believe it is reasonable and valid for the text *widget* to follow the platform behavior.
There have been a number of concerns about changing the behavior when there is a selection. Please note that changing this behavior is *not* my primary objective. In fact, I could live with exactly the way it works now. My primary issue is what happens when there is *no selection*. I maintain that it is clumsy and non-intuitive (see McQ's comment #8 about trees) to not move the caret when there is no selection. To my knowledge, no one has raised any objections to this particular aspect. Having said that, I do prefer that a right click that is not on a selection move the caret. But why should it only work one way? Why should everyone be forced to do it McQ's preferred way, or my preferred way? There is no reason why Eclipse's text editor shouldn't be the most powerful, configurable text editor available. When differences of opinion arise on an issue such as this, I propose that it become a matter of policy that instead of deciding that it should or should not be supported, it should be supported and a preference added to control it (this is, of course, assuming the behavior is reasonable). This allows each developer to configure Eclipse's editor the way *they* want it to work, and everyone wins.
I concur with Nick in both, his concerns and his proposal. This behavior must be configurable. E.g., the Java editor considers the caret a valid selection. The action "Open Declaration" tries to extend a selection of length 0 to cover a correct identifier whose declaration can be opened in an editor. So, it must be the user's decision whether selecting this action from the context menu should behave differently from pressing "F3". Also one word in favor of this behavior: The text editor does not only consist of the text widget but also of the vertical ruler. The context menu in the vertical ruler already considers the location of the right mouse click as the target of the action to be chosen from the context menu. Having the new behavior enabled would make the text widget and the vertical ruler behave more similar.
*** Bug 50467 has been marked as a duplicate of this bug. ***
*** Bug 39329 has been marked as a duplicate of this bug. ***
*** Bug 37908 has been marked as a duplicate of this bug. ***
*** Bug 55200 has been marked as a duplicate of this bug. ***
*** Bug 75069 has been marked as a duplicate of this bug. ***
*** Bug 77988 has been marked as a duplicate of this bug. ***
The last discussion/comment on this bug was in February, 2003. Since then, six other bugs have been closed as duplicates of this bug, including one of mine. Is there any chance of starting up the discussion again? Allow me to distill the comments I see here. First, I think we can dismiss the question of keyboard shortcuts like F3: they should always operate based on the caret or selection, regardless of mouse location. That leaves these options: 1. Current behavior: with or without a selection, right-click operates based on the selection or caret, not the mouse location. (Even if the caret or selection is off-screen!) This is the behavior that motivated at least seven people to file this bug report, so clearly some people find it surprising and irritating. 2. Intermediate change: without a selection, right-click moves the caret to the mouse location and then operates. If there is a selection, right-click operates on the selection, regardless of the mouse location. 3. Complete change: right-click on a selected area operates on that area; otherwise a right-click moves the caret (removing any existing selection) and then operates. My preference is for #3, for the following reasons: a. Right-click is inherently a mouse gesture, and thus should target what's under the mouse. That's where the user's eyes and intent are - at least for me and six others who cared enough to write. b. Options #1 and especially #2 fail the predictability test, especially if the caret or selection has scrolled off the screen: you can't tell what a right- click will do based on what you see. c. The rest of Eclipse works as #3: tree views, list views, and multi-field views (like the plugin.xml editor) all move the selection to the item or field under the mouse when you right-click, then pop up the context menu. So does "Professional Windows" (Word, Visual Studio), as mentioned in this thread. d. Besides being inconsistent with the rest of Eclipse and much of Windows, #1 and #2 are inconsistent with LEFT-click behavior of the entire universe. In my opinion, the argument in favor of #1 that it makes the right-click "hit zone" larger is specious: the whole editor experience is based on using the mouse to target word- and character-sized areas. (See letter 'd' above.) Accessibility is served with larger fonts; purely keyboard operation is served by the context-menu buttons on Windows keyboards, which (correctly, IMO) operate based on the caret or selection, regardless of the mouse location. I have no objection to adding an option to control this behavior. Of course, I would then argue for my preferred default setting...
*** Bug 83301 has been marked as a duplicate of this bug. ***
*** Bug 105176 has been marked as a duplicate of this bug. ***
This bug's third birthday has passed without ceremony. The number of users who have filed this bug is up to nine: one original and eight duplicates. In comment #20, I provided what I thought were reasonable arguments in favor of a change, and I gave what I thought was a good counter-argument regarding the only solid reason given earlier against the change (that it reduces the hit area size). Is there any hope? Can we not at least continue the debate?
*** Bug 130112 has been marked as a duplicate of this bug. ***
Another lonely voice in the wind, another duplicate registered against this 3.75-year-old bug. When it turns 18, will it be able to vote for itself?
Ping. I don't want to be a pain (which is why I haven't commented in this bug for over 4 years), but I wanted to get some dev feedback on getting this into the next release. It'd be great if 3.3 was the release where I could stop the infuriating left-click-right-click dance every time I want a context menu on some Java code element. At least it's managed so far to escape the dreaded RESOLVED/NEVER. :-)
Seconded. Is there anybody in the core editor group who is willing to speak up on this topic? For or against, it would be nice to hear from somebody. One default attitude in open source is "You want it, you implement it," but in this case the patch exists (well, for the 2003 version anyway) so that advice doesn't apply. How can we move forward on this?
This won't happen for 3.3 and if we decide to add this it won't be the default.
Just like that? I could have hoped that thirteen duplicate bugs over four years would have an impact. Even McQ said in Comment #8 that consistency with the host UI can trump consistency with VA/Smalltalk. It is easier to change the right-click behavior to match the platform all the time, because that won't require a Preferences UI change. Saying it will have to be an option makes this a bigger job and thus less likely to happen at all. In order to make this a preference-selectable item, there has to be a compelling reason to keep the current behavior available. Remember, we're talking about the mouse here, not F3 or any other hot key. Can you describe the UI interaction style where it's correct or preferred to have right-click operate on a part of the program that isn't under the mouse?
For the record, our product (Wind River) also gets periodic user complaints about this issue. I'm OK with leaving the default behavior as is, but a preference would be a great relief.
Re comment 29: if you argue it's a Platform/OS thing then it is something that should come from SWT. Please read previous comments for reasons why we have it the way it is.
I referred to working the same way as the platform as a nice way of saying "working the right way, not the wrong way." I'm sorry my attempt at polite phrasing led to a distraction. Regarding the reasons it works the way it does today, I only find two concrete statements in this thread supporting the current behavior: in comment #8 (All VisualAge editors worked this way) and in comment #10 (It makes the hit zone for right-clicks larger). I rebutted both of those in comment #20 and I haven't seen any reply to my rebuttal arguments. Everything else in this thread is either an argument for the other side or a discussion of the details of a change. If I missed any concrete reasons to preserve current behavior or if you want to discuss other reasons, please spell them out and we can talk about them.
+1 on behalf of Symbian. Developers here (using Carbide/CDT) are asking for this behaviour.
(In reply to comment #33) > +1 on behalf of Symbian. Developers here (using Carbide/CDT) are asking for > this behaviour. > Hi Andrew, To make your +1 more effective please use the voting (https://bugs.eclipse.org/bugs/page.cgi?id=voting.html) mechanism. With your vote, this bug will make it into 66 top-voted bugs in platform :-)
Agree with this and have voted accordingly, after searching for some time to find this report. If there are actions in the context menu that are specific to the cursor position, then it is counter-intuitive for the cursor not to shift. If I want to open a type hierarchy for a class, I expect to right-click on the class name and select 'type hierarchy'. To have to manually position the cursor within the class name first feels very clumsy, and hurts the usefulness of the context menu.
I just discovered a UI contradiction quite by chance - clicking the middle mouse button anywhere in the editor cancels the selection (if any), inserts the contents of the clipboard at the mouse cursor and places the caret at the end of the newly pasted text. This behaviour occurs regardless of the current selection and the mouse position. Why was this implemented considering the resistance to right-click cursor shifting? Behaviour noticed in M20090211-1700 (Linux), in every editor I tried (including basic text).
What Luke describes is platform-standard behavior for X applications on Unix: the middle button pastes the clipboard contents at the mouse pointer. On Windows, the center button generally initiates mouse-based scrolling. I'm glad to see the discussion of this bug start up again. Is anybody home at Platform-Text-Inbox who cares to comment? This 6.5-year-old bug now has nine duplicates and 16 votes, and I haven't seen a rebuttal to my specific arguments (a through d) in comment #20. To review: When the text caret or selection has scrolled off the screen, I think having the right-click context menu operate on the (distant, invisible) caret or selection is confusing and unexpected. Following my logic forward, I say that the user intention for a mouse button click ALWAYS follows the mouse pointer, not the text caret or selection. It's where the user's eyes and attention are. This is universally true of left clicks. Thanks to Luke, we know it's also true of center-clicks on Linux. I think it should be true of right-clicks too. Here is a summary of the desired behavior: (1) When there is a text selection and the right-click happens inside it, operate there. (2) For all other right-clicks (that is, no selection exists or the click is outside the selection), remove the selection if any, move the text caret to the mouse pointer, and then operate based on that location. Any comments from the Platform-Text-Inbox people?
Further central-click investigations: I've tried various Gnome apps on my Ubuntu Intrepid installation (TextEdit, Terminal, OpenOffice Writer) and none of them paste on a central click. Dialog boxes (e.g. open/save files) do not support it in their text fields. No Windows applications I could find supported it. So far as I can see it seems to be an eclipse-specific extension. Note that I have no particular problem with it, it's just an anachronism. I found the code in Eclipse that implements it, in org.eclipse.swt.custom.StyledText, in the handleMouseDown function. It's right at the top of the function, under the 'paste clipboard selection' comment. This code is present and active in both the Linux and Windows versions of Eclipse, although it doesn't work in Windows (center-click has no effect) because the getClipboardContent(DND.SELECTION_CLIPBOARD) call returns null even when there is text in the clipboard. I note that in Eclipse, in Windows, center-click does not activate scrolling. On Linux the call works, and so we get the center-click functionality.
Thanks for checking on the behavior of X apps. I use creaky old xterm a lot, and the middle button pastes the current X selection into the text input stream as if it had been typed at the keyboard. This might be where the Eclipse people got the idea. Sorry about the digression. Still hoping for a reply from Platform-Text-Inbox.
>Any comments from the Platform-Text-Inbox people? OK, let's summarize my standpoint: I still like the current behavior better and not just Notepad but also powerful editors, like e.g. UltraEdit, do behave the same. So, it is definitely not a bug but a personal taste/policy. Given we prefer the current behavior and our limited resources we won't work on this. However, if someone wants this badly then a good quality patch can be provided that adds a new preference (off by default) to enable setting the caret on right-click. Note that people also have different opinions on what to do on right-click in presence of a selection: different editors behave differently (e.g. Word vs. WordPad). So the patch should offer all three variants to satisfy all people once and forever.
Created attachment 130504 [details] patch for AbstractTextEdit right-click behaviour against HEAD 1/4/08 Patch to provide the requested behaviour for right-click in AbstractTextEdit. Follows specifications for behaviours 1-3 as laid out in comment #20 and requested in comment #40. Default behaviour is unchanged, also as specified in comment #40. Patch was shifted from StyledText, as suggested by Lynne in comment #5. Happy to modify the patch as necessary after review, I am new to patching eclipse so I expect there are things I could have done differently!
Sorry, meant to add that the patch adds a property to TextEditorDefaultsPreferencePage, found at Window->Preferences->General->Editors->Text Editors. "Right click moves caret when:".
Thanks for the patch Luke. It starts into the right direction but needs some more work: - the patch does not work: it throws an IAE when clicking outside of text - the implementation should be at the text viewer level with API that allows to set it (take a look at how the enrich mode is implemented) and even better would be to get this at StyledText level (filed bug 271333 to ask for this) - don't catch exceptions and leave the handle code empty (must at least have a comment) - also declare the constant in AbstractDecoratedTextEditorPreferenceConstants and use this in the preference page - preference wording: I would change it to: Move caret on right-click: - replace 'a' as mnemonic: this is already taken for 'Apply' - add "right-click" as preference keyword - respect formatting (e.g. no space before assignment) and style (e.g. use 'f' prefix for fields) - I would place the preference below "Smart caret positioning..." - add your copyright info to the header of each file in the following form: name <e-mail> - bugzilla summary - bugzilla URL e.g. Dani Megert <dani@eclipse.org> - this is a bug - https://bugs.eclipse.org...
Thanks for your feedback! An IAE, how embarrassing! I thought i'd tested quite a bit but i'll check again. I did look at implementing them at the TextViewer level but I thought there might already be a few too many ITextViewerExtensionX interfaces. Is that what you're suggesting (ITextViewerExtension9)? Or do you want an patch to TextViewer itself? I'll look at enrich mode as you suggested. I looked at AbstractDecoratedTextEditorPreferences, but decided not to patch it as I was patching AbstractTextEditor, not AbstractDecoratedTextEditor. Is that still an appropriate place for the preference if I patch TextViewer? Apologies for formatting, naming and commenting issues, I tried to be neat and did read through the development conventions and guidelines but I figured there'd always be something to catch me out. Re: copyright info, many of the files have been patched but did not have this appended? I didn't want to spam my name everywhere, so I just put it in AbstractTextEditor. Thanks again for chasing this, I'm on holiday but will revise the patch first thing after Easter.
Hi Luke, we don't need to hurry on this for two reasons: 1) API freeze has passed which means this will have to wait for 3.6. 2) your contribution will most likely hit the legal barrier so that we need to get legal review and approval of yozr code. This deadline has passed for 3.5. 3) I still hope that we get the implementation (not the preferences) from SWT, which would change the patch quite a bit Yes, adding the method to a new extension interface is the right way. The reason why the preference is duplicated is to have all the higher level (AbstractDecoratedTextEditor and its subclasses) preferences at the same place.
Happy birthday to this bug. It's seven years old this week. Has there been any movement since April, when the patch missed the cutoffs for release 3.5? I gather the patch needed rework and possibly legal review, and might need to be redone entirely if implementation comes from SWT. Is any of that happening? Just asking as an interested observer.
Hullo Allan :) As it turned out, lecturing a class was a lot more work than I thought. I have some marking to finish, but I haven't forgotten about this bug! Back into eclipse work probably next week.
FYI, I'm no longer doing eclipse-based dev (have switched to Netbeans), so I no longer plan on patching this.
*** Bug 304484 has been marked as a duplicate of this bug. ***
*** Bug 277411 has been marked as a duplicate of this bug. ***
So I guess this bug's eighth birthday passed just this June. :) Any further updates? I just want to add my voice to the crowd in support of getting this fixed ASAP. (Is there any way I can use ALL my allowed votes on one bug? No? You sure? ;) I just recently switched to Eclipse as my primary IDE (from Visual Studio); this highly surprising and annoying behavior was one of the first things I noticed. Right-clicking brings up a context menu, and it seems to me that the context should be the thing I right-clicked on. It makes little sense for right-clicking on an identifier and selecting "Open Declaration" to do nothing at all, or, even worse, open the declaration of some entirely other identifier that does not even appear on the current screen. If there really are people who prefer the current behavior, I agree it should be made a preference. But I really can't see any argument for preserving the counter-intuitive behavior. As far as I can tell the only real argument for the current behavior is that it increases the size of the "target area" to the whole window. Quite aside from the fact that this does not make sense (the window encompasses many targets, and in any case, why should the whole window be a right-click target for an element that is not necessarily even within the window?) most keyboards these days come equipped with a perfectly serviceable context menu button, which expands the "target area" to the entire observable universe, so long as your keyboard is within reach. ;) To summarize, I'm very much with Ron Baldwin on this one. I don't see that the current behavior makes any kind of sense (from an IDE UI perspective). I also agree that this is NOT an SWT/platform text widget behavior issue. This is an Eclipse IDE behavior issue.
*** Bug 526603 has been marked as a duplicate of this bug. ***
If you don't mind I'd like to finish this task
