Bugzilla – Full Text Bug Listing
| Summary: | [block selection] problems with bracket inserter and Tab | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Anton Leherbauer <aleherb+eclipse> |
| Component: | Text | Assignee: | JDT-Text-Inbox <jdt-text-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, davidb.arbete+bugs+eclipse.org, denis.antonov, eclipse, kamil.kolaczynski, kaser, remy.suen, sergey.grinko, timo.rumland |
| Version: | 3.5 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 264147 | ||
|
Description
Anton Leherbauer
Affects both BracketInserter and normal content assist. Both should disable the magic when in block selection mode and multiple lines are selected... perhaps they should be disabled anyway if the selection spans multiple lines. I fixed the most annoying problem, i.e. BracketInserter deleting the extent of the selection when typing an opening bracket. Fixed > 20090426 Not so sure about content assist and tab. Content assist already behaves strangely when the selection spans multiple lines; perhaps this should be revisted as a whole, considering block selection and other multi-line scenarios. Tab is different again - I completely understand the common use case of wanting to insert a tab character on each selected line. However, should we really take away a common and expected shortcut for "Shift Right" - why should this not work in block selection mode? Dani, what's your view of this? I think the OP is right and we should only map "Tab" to "Shift/Indent" when the real operation of inserting a tab does not make much sense. Since in block selection, inserting a tab does make sense, we should do exactly that. The user can still choose the shifting and indenting actions from the source menu. Re content assist: agree. re Tab, I think what Anton meant was that he likes to add a tab to the block selection. I suggest we do this in case the width of the selection is 0 but indent/left shift in all other cases. (In reply to comment #3) > Re content assist: agree. > re Tab, I think what Anton meant was that he likes to add a tab to the block > selection. I suggest we do this in case the width of the selection is 0 but > indent/left shift in all other cases. I think in block selection mode the tab should always be inserted literally. The reason is that block selection behaves as multiple individual selections. It is not observed as multi-line selection in the usual sense. It's also hard to explain why one can insert a space, but not a tab, when the selection width happens to be >0. >I think in block selection mode the tab should always be inserted literally.
Well, I disagree. Either we leave it as is or we allow to insert a Tab with length 0. Tom to make the final call between the two as he's the block selection man.
(In reply to comment #4) > It's also hard to explain why one can insert a space, but not a tab, when the > selection width happens to be >0. The same could be said from the tab behavior in linear selection mode: inserting a tab would perfectly make sense - it's just not something that one typically does, that's why tab is mapped to a frequently used command. The rationale for this decision should be that we only map tab to the indent/shift command where literally replacing the selection with a tab character would be a "very unusual" thing to do. Of course, the question is whether replacing a non-empty block selection with a tab character on each line would be very unusual... hard to say. If we go down the way comment 3 suggests we would still be consistent with the current behavior that only a "non-empty" and "multi-line" selection triggers the indent operation. Dani should we aim for 3.5 for this? (In reply to comment #6) > (In reply to comment #4) > > It's also hard to explain why one can insert a space, but not a tab, when the > > selection width happens to be >0. > > The same could be said from the tab behavior in linear selection mode: > inserting a tab would perfectly make sense - it's just not something that one > typically does, that's why tab is mapped to a frequently used command. As long as the selection is inside a line, I can insert a tab. If I perceive a block selection as a set of linear in-line selections, I would expect I can do the same. >Dani should we aim for 3.5 for this? If today's test pass goes well and once bug 267804 is off the plate we could shoot for this one but keep in mind that we go into RC-mode next week. *** Bug 293548 has been marked as a duplicate of this bug. *** The problem with a vertical block and the TAB key and SHIFT+TAB key TAB character is inserted always in the beginning of the text, but not to the point of separation of the vertical block. 1. Open any file in the editor. 2. Hit <Alt>+<Shift>+A to go into Column Edit Mode 3. Use the <Shift>+<Down> to mark several lines in middle text. 4. Press key TAB Result: All text is shifted to the right. Expected: should fit only text that is to the right of the vertical separation. Isn't the formatting of text in columns the primary use case for a block selection mode? Comparing to other editors like Notepad++, Sublime etc., I think inserting TAB in a block (or "column"-) selection mode at the vertical separation should be the default behaviour. I for myself often format more complex Enums in columns for better readability. Currently, I copy-paste the code into one of the above editors, format the code, and paste it back into Eclipse. I agree, this is ultra annoying that we cannot just insert tabs in the block selection mode. It is very different than any other text editor is doing during the block selection. Is anyone (in the world :) ) satisfied with the current behavior? I can hardly imagine this. Are there any plans to fix this? (In reply to Kamil Kolaczynski from comment #12) > I agree, this is ultra annoying that we cannot just insert tabs in the block > selection mode. It is very different than any other text editor is doing > during the block selection. Is anyone (in the world :) ) satisfied with the > current behavior? I can hardly imagine this. > > Are there any plans to fix this? High quality patches are welcome. 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. If you have further information on the current state of the bug, please add it. 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. My current version Version: 2019-09 R (4.13.0) Build id: 20190917-1200 This problem is Active. comment 10 I have the same problem. The expected behavior, described by Sergey in his comment posted 2016-09-06 10:22:51 EDT, is a valid one. It works the same way in Notepad++, ABAP GUI code editor and I assume at a lot of more environments. Please fix it, I think many people would be grateful! |