Split window Lock in Place document overwritten by Quick Search result

User avatar
auxbuss
Posts: 241
Joined: Mon Nov 30, 2015 9:50 pm
Platform: Mac
Contact:

Sat Sep 14, 2019 2:41 pm Post

1. Open a document in editor
2. Lock in place (opt+cmd+L)
3. Split editor window vertically (cmd+")
4. Quick search something (ctrl+opt+G)
5. Select a result
6. Result document opens in locked window and Lock in Place is deactivated.

Expected result: Result document opens in second window and Lock in Place remains.

If, at 4, you select Full Project Search, which opens a Collection, then any document selected from the Collection opens in the second window, as expected.
Image

User avatar
auxbuss
Posts: 241
Joined: Mon Nov 30, 2015 9:50 pm
Platform: Mac
Contact:

Wed Oct 02, 2019 7:00 pm Post

Gonna ping this, because I'm doing a second edit and hit this issue ten times a day.

Appreciate y'all are in Windows-delivery mode – must be hell – but would appreciate a yeah or nay on this.
Image

sc
scshrugged
Posts: 443
Joined: Wed Feb 10, 2016 6:55 pm
Platform: Mac + iOS

Wed Oct 02, 2019 11:36 pm Post

After reading (specifically para. 2) the following from the Manual––Sec. 12.2.1, Locking the Editor––I took it as expected behavior. I presumed the reason for the different behaviors between Project Search and Quick Search (QS) was that QS's frame of reference is the active document as indicated in the QS field, prior to clicking into it. I click into (or otherwise make active) the other editor before initiating a QS. Maybe that will help you, for now.

Locking the editor inhibits external navigation from impacting the locked editor. This means that clicks in the binder, corkboard or outliner (when Navigate ▸ Corkboard|Outliner Selection Affects ▸ Other Editor is enabled) and inspector bookmark double-clicks will be blocked. This makes it easy to keep your editing session stable while using other tools.

What locking will not do is prohibit actions taken from within the editor itself, or those we might consider intentional. This includes use of editor navigation functions (such as history), manually dragging items to the header bar, hyperlink usage or menu navigation commands. Locking is meant primarily to keep the interface from taking actions that the software would ordinarily take automatically. Locking will not inhibit intentional actions that you make. These actions will navigate as requested and cancel the lock state in doing so.

An exception to locked behaviour is when it makes sense to scroll your view, or select items within it, based on an external selection that otherwise would impact the editor. If when using a locked group view you click on a portion of the outline that is contained within that view, then the editor will scroll to the right spot and select that item. For example, in a large locked corkboard, you can jump to individual cards by clicking on them in the binder, or jump to sections of your text in a Scrivenings session. This behaviour leaves the lock intact, so if you later click on something else outside of the view nothing will happen.
I'm a Scrivener user, not an L&L employee.