Description: The Navigator is excellent for jumping around in a document. However, it is not possible to use the "jump points" for selecting an area. Steps to Reproduce: 1. Open attached document 2. Move to line 10 3. Open navigator F11 4. Shift-click Section 3 in navigator Actual Results: Cursor jumps to Section 3 Expected Results: Area between line 10 and Section 3 is selected. Cursor jumps to Section 3. Reproducible: Always User Profile Reset: No Additional Info: I want the behaviour to the the same as if I had shift clicked on Section 3 in the document instead of in the Navigator. In this simple document it is not a big deal but when there are 10s of pages between section 3 and 5 it suddenly is.
Created attachment 185987 [details] actual+wanted behaviour
Created attachment 185988 [details] Test document
That could be an interesting feature, but would need to be only possible for some elements in the Navigator (like headings, fields, bookmarks, hyperlinks...), and we would need to check if it interferes in any way with potential multiselection implemented for bug 129610. Copying UX team in for their opinion.
The Navigator aims to navigate not to manipulate. In my opinion we should keep it simple. However, the request about multiselection has been done before (and wasn't questioned). Multi-selection means to ctrl+click tree items to toggle it's selection state. Shift+click in the tree would select all items up to the current position. There can't be a cursor position in the document. *** This bug has been marked as a duplicate of bug 129610 ***
Maybe rather a "won't fix" then, because this is less about multiselect but more about using the navigator items as a "jump point" to select a range of text (and maybe tables or other things that can be selected together). "Won't fix" because there's always an active selection in the navigator, and therefore using Shift + Click should trigger a navigator multiselection when it can (once it's implemented, and as it's already implemented in e.g. Draw). In the specific case of headings, I assume such multiselection should be the equivalent of selecting multiple headings in the text with Ctrl key pressed.
Just to make it clear: The mulitiselection idea (Bug 129610) would not solve my issue and it is in no way the same problem. I am an emacs user, and I really love CTRL-space to set mark, then move to another location, and then being able to cut the area between the mark and the current cursor location. So another way that would solve my issue would be to have a way to turn on selection mode, then navigate (by hand or by Navigator) and then have a selection between the start point and the current cursor location.
The request boils down to not change the document focus when interacting with the Navigator and to just scroll to the respective position. I think wont be comfortable for the majority of users (who not even know about Emacs). And actually it shouldn't be a frequent use case anyway. You could realize the function per macro. And perhaps you may benefit from the various selection modes we provide, and which are easy to overlook. Depends of course on your specific use case. My take is still WF.
Reading targets for doing a <Shift>+<click> selection via the Navigator deck--i.e from current edit cursor to top of object picked from SB--would allow precise selection without having to scroll the canvas, or move the edit cursor (until selection is finalized). Would be useful. Though not sure it can be made keyboard only friendly. @Jim, what do you think as to feasibility and scope? Writer seems reasonable, not sure of utility cross module.
This was just asked in the LO users' mailing list: > This would seem to be a common thing to do for a writer. I'm missing it. > > I'm in LO Write. I need to cut a multi-page block of text between two > bookmarks, save it and insert the text in a different chapter. The insert > is easy part. > > How do I cut a block of text between two bookmarks without dragging the > cursor over it? This is an obvious was to do what the user asked for. Is there another?
(In reply to Eyal Rozenberg from comment #9) > This is an obvious was to do what the user asked for. Is there another? Ok, so, there is, sort of - using extended selection; but - one still has to scroll, which is not good enough.
(In reply to V Stuart Foote from comment #8) > @Jim, what do you think as to feasibility and scope? Writer seems > reasonable, not sure of utility cross module. Here is a link to a proposed patch to provide the wanted behavior for Writer: https://gerrit.libreoffice.org/c/core/+/151157 Shift + double-click or Shift + Enter on a content entry other than Frames, Images and OLE objects, makes a selection in the document from the current cursor position to the navigated content position. Selection does not happen if the current cursor position is in a table, footnote/endnote, header/footer, frame, image, or OLE object.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/50deb478e97aa9cfd023c5fa2f9d567b0b5797c2 tdf#154211 SwNavigator: select range of content by shift + double- It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jim, you can mark as assign, resolved, so on... I will come back later with Verified. Everything working fine in 7.6. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4f93995f2262cde0b16bacc83f4ba3c6161ada7f CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Was not working in Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
(In reply to BogdanB from comment #13) > Jim, you can mark as assign, resolved, so on... I will come back later with > Verified. Everything working fine in 7.6. Done. Thanks for the reminder.
Verified with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4f93995f2262cde0b16bacc83f4ba3c6161ada7f CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded