Community
Participate
Working Groups
Version. This is 4.10.0, but this is missing from the form's options. Component. I can't find anyway to ID the component so I'm guessing. Steps: 1 When editing C code, SHIFT-click at the 'w' here: wally();// cube(3*10*uuu);shell(.31); and drag to the semicolon. Expected: wally(); selected. https://i.imgur.com/msDWAL7.png Observed: wally();// cube selected https://i.imgur.com/pG84EL9.png Expected isn't based on any docs. I can find no docs for this operation. It's based on the reasonable expectation that word select is supposed to follow language syntax.
Good grief! Is there really no body edit option here?? Correction: s/SHIFT-click/double-click/
(In reply to Chris Jordan from comment #1) > Good grief! Is there really no body edit option here?? Welcome to Bugzilla :-)
Created attachment 281290 [details] Image from https://i.imgur.com/msDWAL7.png
Created attachment 281291 [details] https://i.imgur.com/pG84EL9.png
> This is 4.10.0 I assume the version you are referring to is the Eclipse version - versions in Eclipse are complicated and long, but CDT has its own releases with its own versions. I am assuming it is part of Eclipse 2018-12 release, which means CDT 9.6.x
(In reply to Jonah Graham from comment #2) > (In reply to Chris Jordan from comment #1) > > Good grief! Is there really no body edit option here?? > > Welcome to Bugzilla :-) Slight correction: welcome to old versions of Bugzilla :-) Newer versions, such as the one deployed at bugzilla.mozilla.org, allow you to edit comments (and even render Markdown!).
Sergei, this may perhaps make a good bug to tackle. I am quite curious if this affects other editors or if it is CDT specific.
I can't reproduce this in a recent CDT (2019-09). The selection becomes "wally", which I would say is the expected behaviour (rather than "wally();" as suggested).
(In reply to Nathan Ridge from comment #8) > I can't reproduce this in a recent CDT (2019-09). The selection becomes > "wally", which I would say is the expected behaviour (rather than "wally();" > as suggested). Oh, my bad, I overlooked the "and drag to the semicolon" part of the steps. With that step, I can reproduce in recent CDT. I had no idea we had a mode of selection that worked differently if you started with a double-click :)
(In reply to Nathan Ridge from comment #9) > I had no idea we had a mode of selection that worked differently if you > started with a double-click :) It looks like the decision for how far to extend the selection comes from StyledText.getWordNext(), which uses TextLayout.getNextOffset(), which, at least on GTK, calls out to pango_layout_get_log_attrs() [1] to find the first character after the current selection which has the "is_word_end" property [2]. Pango's word boundary semantics are in turn documented to be based on Unicode TR 29 [3]. So no, there is no language-specific logic for it :) It looks like StyledText does support customizing this behaviour via sendWordBoundaryEvent(), where a client can register a MovementListener, and StyledText will give the listener the opportunity to customize the next offset via MovementListener.getNextOffset(). And in fact, TextViewer does register a MovementListener for this purpose, "TextDoubleClickStrategyConnector". However, it looks like this only handles selecting the initial word, and not extending the selection for the next or previous word, which just fall back to StyledText's default behaviour. TextDoubleClickStrategyConnector could in principle be extended to handle extending the selection. TextViewer in turns allows clients to customize the behaviour by providing an ITextDoubleClickStrategy via SourceViewerConfiguration.getDoubleClickStrategy() (and CDT provides one called CDoubleClickSelector). So, in principle, language-specific logic could be added, though I think the ITextDoubleClickStrategy interface would have to be extended for this purpose. [1] https://developer.gnome.org/pango/stable/pango-Layout-Objects.html#pango-layout-get-log-attrs [2] https://developer.gnome.org/pango/stable/pango-Text-Processing.html#PangoLogAttr [3] http://www.unicode.org/reports/tr29/
> I had no idea we had a mode of selection that worked differently if you started with a double-click :) If we had more user documentation, we might have fewer bugs! :)
> So no, there is no language-specific logic for it :) I'm quite surprised. I can't recall the previous time I encountered this in a C editor. It's a substantial time saver. Is there some reason this isn't required by Eclipse users, do you think?
PS Same applies to selection by keyboard, so to > 1 When editing C code, SHIFT-click at the 'w' here: > > wally();// cube(3*10*uuu);shell(.31); > > and drag to the semicolon. add Or place caret before 'w' and CTRL+SHIFT+Left Arrow twice.
(In reply to Chris Jordan from comment #13) > PS Same applies to selection by keyboard, so to > > > 1 When editing C code, SHIFT-click at the 'w' here: > > > > wally();// cube(3*10*uuu);shell(.31); > > > > and drag to the semicolon. > > add > > Or place caret before 'w' and CTRL+SHIFT+Left Arrow twice. I do get slightly different behaviour here: the selection becomes "wally();// " rather than "wally();// cube". Moreover, if I add a space before the comment: wally(); // cube(3*10*uuu);shell(.31); Then, with the keyboard, the selection becomes "wally(); " (whereas with double-click drag, we still get "wally(); // cube". I'm not sure what is causing the difference between keyboard and mouse-drag, though hopefully the pointers in comment 10 are a good starting point if someone would like to investigate.
(In reply to Chris Jordan from comment #12) > > So no, there is no language-specific logic for it :) > > I'm quite surprised. I can't recall the previous time I encountered this in > a C editor. It's a substantial time saver. Is there some reason this isn't > required by Eclipse users, do you think? My guess would be that most people don't know about the double-click + drag feature. Moreover, code styles where there is no space between a code and a comment are rare. As a result, I think not many people have noticed this edge case bug. Note that, as per the previous comment, the behaviour with keyboard + space before the comment is reasonable.
(Previously accidentally set Target Milestone when Version was supposed to have been fixed.)
Thanks Nate for the analysis. This equally affects Java and a number of editors I tried it with. So I am resetting this to the Eclipse Platform project. If this must be solved in a language specific way (i.e. in JDT) we can apply the same fix for CDT (and send notice to cross-project-issues so other language editors can adopt).
Created attachment 281306 [details] animated gif of selection behaviour
> This equally affects Java and a number of editors I tried it with. So I am resetting this to the Eclipse Platform project. Thanks Jonah.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
