Outline-mode editor functionality

[dbc183c7]

Good evening (our time),

I work from the outline mode in a two-editor arrangement. (Outline in a left editor; text/scrivening in a right-hand editor.)
- I have found that when I merge two documents in the outlining editor, that editor gets changed to text mode, even when the outline is locked.
While I do understand the ambiguity of design-choice possibilities, this happens even when "automatically open selection in other editor" is set on and the second, 'text', editor does in fact receive the newly merged document. And it results both in the duplicated display of that document in the editors and in my inability to easily append the new document further in the outline.
Is there a way keep the outline mode in effect in this situation (perhaps dependent upon the editor's locked state)
yet have the merged document open in the 'text' editor as it does?
(The mode change and duplicate display of the document also happens when I do the merge in the Binder, a search result, a collection.)

- Wish list: I would find it of use to be able to paste text from the clipboard, directly into (onto) an outline editor and get a new document. (Preferably, formatted per my default template.)

[AmberV]

You are correct! I just checked on the Mac version, and a lock on the editor does inhibit the Merge command from secondarily loading the contents of the merge into the editor. I’ll make sure that minor variation in behaviour is made note of somewhere.

By the way, Scrivener has a history feature just like your browser. Ctrl-[ will suffice to get back to the outliner after this happens without too much hassle—or you can of course just click the back arrow button in the editor header bar. Additionally if you ever find yourself in a situation where you’d like to view the parent of the item you are looking at, there is a command for that too, the View/Go To/Enclosing Group command.

As to pasting text raw into a list, I don’t know about the feasibility of that, but do try drag and drop, that is something we managed to add to the Mac and it might be implemented on a PC as well.

[dbc183c7]

Thanks, yes, I have become quite familiar with the step back into history, which does get me back into the outline.
However, in my use of the back-step, Scrivener loses its focus on such an outline view, even though the editor's header highlighting suggests otherwise. The only keystroke way to get the outline focus back is to Ctrl-Tab around. And even then, the focus comes in at the top of the outline, away from where I was.
(I realize there may be some overhead in keeping each historical view's specific selection/location; an arbitrary focus even at the top of the outline would be quicker/better than Ctrl-Tab'ing around -- and remembering to first step back into history before the Tab about ... else I'll not have the focus when I land.)

As for the 'enclosing group', that seems to operate in the 'other' editor, so it doesn't get me back into the outline.

It would be 'nice' were a locked editor view/mode to fully lock it EXCEPT for actions actually applied in that editor by the user directly.

I paste a new document into existence from copied text quite often in my current software (InfoSelect). It is not a situation of my working in Windows' File Explorer, working with a full external document per se. It is rather that I find several sentences, a paragraph or two in something I'm reading online, in a PDF or DOCX, a quote or extract worth bringing over. All I need do is/would be to select the text involved, Alt/Win-Tab to the Info/Scrivener window, and paste -- a new document, with default template applied.
(It is some steps quicker than the Scratchpad -- which is useful -- and requires no mouse handling.)

[AmberV]

It would be ‘nice’ were a locked editor view/mode to fully lock it EXCEPT for actions actually applied in that editor by the user directly.

Yes that is the basic idea behind the feature, though with one small change to the phrasing: “applied to that editor”, since there are valid ways to specifically load content in an editor from outside of it that would feel awkward if you couldn’t. The main goal is to keep things intentional as best as possible.

Regarding the focus issues and having to Ctrl-Tab about, that is a known bug that needs to be fixed.

[dbc183c7]

I am pleased that attention will be given to (keyboard navigation) focus: You've likely seen my posts about specific instances of its loss that I have encountered. Reading your note here, I'll resist posting about additional instances. (Depending on the my use-frequency of a particular instance however, resistance may be ... futile. )

And I am also happy to hear that the Tab-about is being looked at. Relatedly, thinking about changed or added keystroke navigation for v3, will the changes be separately documented? In even my early stage of transition, I have already moved some of the multi-hit keystrokes (ie, Ctrl-g + Ctrl-...) to more accessible single action strokes/combo-strokes (eg, I have the project search set now to F5),
and moved some of the latter, but less likely used (by me), to the realm of multiple strokes.

Broadly related: The highlighting for the active editor window is obvious enough for me to know where I'm at, but it is not so when the attention is on/in the Binder/Collections column. (I do intend to look at tweaking the color etc. for that column at some point.)

Re locking: Given that the key is left in the outside of the lock for the editor, what specific content loading is permitted to turn it? (Or conversely, for which actions is the view actually fixed?)
Though my Scrivener-state is still introductory (perhaps because of it), the lock's lack of security leaves the editor's stability a rather unpredictable situation (given its description and apparent purpose). And though yes, while having to consciously unlock the editor to do a particular something from outside might be deemed an unnecessary, even frustrating, routine step, it would not be the first time Scrivener enforced a two-step procedure to safeguard its users' content: Even with my very limited experience of Scrivener, Trash comes to mind.
If outside overrides are in fact common enough to make separately unlocking the editor a nuisance, perhaps some other procedure (a popup for those who might like a more stable situation) or description, or the above requested list of actions?

[dbc183c7]

The circumstance that started my thinking on this was when I used a Favorite Link to get to a CONTAINER while working in an outline:
The editor's setting switched to doc mode. (Ctrl-3: I got back to the outline view.)
What I started thinking was that it would be nice (for me ) were Scrivener to keep the pre-action setting (whichever) in particular cases. In this case, were Scrivener to sense the favorite's item type, and if it were a container, if it had text content itself or not (which it already 'knew' for the icon's sake, a 'bit' somewhere?), and handle the editor mode accordingly ... open the container in a text editor mode or keep the outliner.
(But then, if a textless container, which view of either the cork board or the outline? Design decisions, functional choices ... .)

[dbc183c7]

It would be nice to have a button on the editor headers to lock the space.

I recognize the irony of my even thinking about using the mouse!

[AmberV]

It would be nice to have a button on the editor headers to lock the space.

There are a lot of buttons that would be nice on the header bar depending on what you are doing. We’ve gone for the approach of collecting them into one button on the document icon in the header: right-click and lock (among other things).

Of course there is also Ctrl-Shift-L.

And though yes, while having to consciously unlock the editor to do a particular something from outside might be deemed an unnecessary, even frustrating, routine step, it would not be the first time Scrivener enforced a two-step procedure to safeguard its users’ content

Are we talking about the same thing here though? Locking the editor is an interface decision, like whether or not to split the editor, or cause all clicks in the binder sidebar to load in the left split regardless of where the cursor is. I wouldn’t say things like that require double-confirmation in the form of manual switching or warning dialogues as a matter of course to disable or change.

In this case, were Scrivener to sense the favorite’s item type, and if it were a container, if it had text content itself or not (which it already ‘knew’ for the icon’s sake, a ‘bit’ somewhere?), and handle the editor mode accordingly … open the container in a text editor mode or keep the outliner.

The idea here is that what you are doing with your data might have more precedence over the topology of the data, that if you have been clicking on folders and working on them as corkboards, the software should continue doing so until you yourself say otherwise. That isn’t a universal truth or anything of the like (after all we do dynamically treat text containers differently from folder containers by default), but I think in this case it is well applied.

Speaking of which, if text-first is what you want, then there might be your solution: dispense with using folders and switch to a pure text node outline. Under default settings Corkboard, Outliner and Scrivenings mode will all become secondary features you must invoke manually.

[dbc183c7]

Ioa,

Re header lock button. Thanks; with my keyboard focus I'd not used that menu button yet. (Though I probably clicked on it early without much sense as to how I would use Scrivener.)
Of course, this thought was for those rare times my hand was 'inadvertently' on the mouse -- inexplicably off the board, away from Ctrl-Shift-L.

Re "Talking about the same thing" -- Probably not. Water under the bridge? I was a somewhat different S. user even just five months ago back to June.
More recently, I've found that my editor lock manipulation is 'frustrating' only seldom; I'll try to track those specific moments. (However, I do tend to lock/unlock editors quite a bit. Perhaps it is more than 'intended' by Scrivener's design, maybe still due my ignorance of some S. tool.)

Digressing (as I sometimes do), Re 'locking the editor' -- If I swap a locked left editor with a right unlocked editor, the 'new' left-hand editor is locked and the new right editor is unlocked. (And if the pre-swap locked editor is a 'text', it doesn't swap; it duplicates into the right editor, unlocked.)
Is this for the sake of continuing to work in the a locked editor? And to 'sidebar' that pre-swap text? (I expected the locked state to go with its document.)

Re "if text-first is what you want" -- What I think I was looking for was a clicked-item nature-and-content "first" consideration. And my solution for this was to have a ‘Shortcuts’ Collection that has various references/links to items throughout the project rather than using Favorites: I find the shortcuts to often be a quicker route to my favorite items than Favorites (though it requires the mouse at one point), and to handle the linked 'thing' as I was thinking.

(Draft & Trash don't link.)

(This ability is among those that Scrivener has that I had suggested for that workhorse, nearly 10 years ago -- Now, if only I could click-drag actual items onto the links to relocate them ! ... Who needs the Binder then? cf. my post about being able to show more Collections.)

Digressing a bit more -- The right-hand editor thinks 'corkboard' every time I select a container or multiple documents. While the editor does stay in 'outline' if that's where it was,
if it had been in outline mode for my latest collective view -- but with an intervening doc/text mode -- the editor responds to my containers etc selection with the corkboard.
( Curiously, 'opening in the other editor' works via keyboard (Ctrl-Alt-Enter) and via the menus, clicking or keying -- but right/context-clicking the mouse's 'opening in other editor' doesn't work for me.)

(I will not blame Scrivener's complexity -- which I do appreciate -- for my inexperience, which I have learned from decades of programming that users do tend to do. My posts are certainly not complaints. Very much most of them have nothing to do with anything I thought Literature & Latte ‘promised’, had set forth as its intent for the software: Any irritation inferred from them was rather an expression of concern that S. would not in the end serve as the clear step up for which I peculiarly had been looking.
Such concerns are my own undertaking. Let it be known that
Despite the disappointment and abandonment of S. by the only other user I knew, whose intents were somewhere up my alley, and
Despite Scrivener’s sometimes struggling interactions with the rest of the way I use my PCs (noted elsewhere),
There is much of S. that I appreciate, abilities and tools that I had in fact wanted (and some suggested) for the ‘next version’ of my workhorse of 20 years, Info Select.
I am glad to be ‘here’.)

Thanks for that header 'lock' menu choice -- I'll work to remember it.