I upgraded to macOS Mojave (10.14.1) awhile back. I then noticed that when I opened a document in Scrivener, it would open to the beginning of the chapter I’d last been working on, then take several seconds to go to the highlighted last line I was on. But now, it has started only going to the chapter and not the line (I have to manually scroll to find the highlighter line myself). Anyone know how to fix this?
Firstly, if the cursor is actually in the text already and you have a line highlight (or selected text, if that is what you mean), then you needn’t spend a bunch of time scrolling to find that point: hit ⌘J, which is a common shortcut in most native Mac programs to scroll the editor to the current selection point.
Secondly, when restoring a project window with a Scrivenings session, it won’t scroll to the selection automatically, but rather wherever the scrollbar was before. So if you hit the Home key before closing, then it will open at the top, even if you have a selection within the session somewhere (you can still use the ⌘J trick since scrolling doesn’t change what is selected). So maybe that’s what you are seeing.
Thanks, but the Command J thing does not work. It only works when I have a line highlighted, then go elsewhere in the given chapter to look at something. It will then return me to the highlighted line, but even when I switch to a different chapter in my document, then return to the chapter where the highlighted line is, it will not return me.
As I said, the auto return function was working fine before I switched to macOS Mojave, then it got slow to relocate the last line I was on, then it stopped doing it altogether.
Sorry for the delay in getting back with you. Your response got pushed down the list while I was on holiday and lost on page two.
I need a little clarity on what all of that means. What is a “chapter” and a “document”, in relation to how you use Scrivener’s features?
As far as Scrivenings sessions go, their ability to store your last selection is limited. So if by “chapter” you mean something along the lines of clicking on a different folder with several items of text in it, and then later clicking on another—then yes, we wouldn’t expect to see your old selection saved. There isn’t really anywhere to save that information, and Scrivener has never worked that way in the past.
There is one exception: history, and if all you are doing is clicking on Folder A, Folder B and then finally Folder A again—then you probably be using history anyway. Just click the Back button at the top of your editor, or use the handy ⌘[ shortcut. History does indeed store your Scrivenings session cursor position or selection. It will always be centred in the editor vertically, when using history. So it is not only more convenient than finding the right thing to return to and clicking on it manually, it has signficant advantages where it comes to retaining your state. It for example can even store when you view something in a different view mode—maybe Scrivenings isn’t usually how you view a chapter folder, but if you did view it that way in the past, history will return you to that mode, even if clicking on the folder in the binder loads clipboard.
So hopefully that tip helps for that part anyway.
I still can’t explain why the software would load a project without the prior selection state already selected and in the middle of the screen. I’d need some specific instructions on how to arrive at that condition, unfortunately.
“Specific instructions” in this case can include a sample project, sent in to support. Or step by step instructions, starting from a blank project and telling us which options, settings and content it requires before it stops remembering selection state on reload.
I have the same problem, but using Mac OS 10.13.6.
My impression is the the “reload pane/chapter/whatever” operation isn’t doing what it ought to do. I’ve spent some time trying figure out what it does. (More time than I’d like. I’m testing stuff before I commit a lot of time to Scrivener and this is one of several issues that concern me. Backups are another.)
I am not in typewriter mode. My expectation is that Scrivener (or any other editor) would honour where the user was within the document, restoring the top-left (‘origin point’) position if I were move to another chapter, then (eventually) back. (For other languages, e.g. some of the Asian languages, the ‘origin point’ to be honoured will be elsewhere e.g. bottom-right, etc.)
What seems to be going wrong—AFAICT—is that Scrivener is remembering the line the cursor is on, and bringing the revived document back with that line in the centre of the pane. What it should be doing is recording where the origin point was, and “reviving” the document to that point.
My impression is that it’s simply using the wrong thing to resort the position. It makes me wonder if someone has borrowed thinking or code from tyepwriter mode, and not appreciated that this will muck things up for users moving from one chapter (etc) to another in non-typewriter mode. (In typewriter mode, I can understand basing position on cursor position.)
The command-[ trick doesn’t work for me, It does exactly what already happens when you just move from one chapter (etc) to another.
While I’m writing:
- the cursor is lost on moving from one chapter to another, It’s not presented when you move to a new chapter so you’ve no idea where your insertion point is/was. That leaves the user doing a “where was I?”, breaking the work flow. (A partial workaround is to turn on current line highlighting. I wouldn’t normally use this, and it still doesn’t so the cursor position within the line when the chapter, etc., is “revived”.)
- I’d like to see the bounding box in highlight lines gone or there be options to control it. To me there’s a difference to highlighting and boxing. (FWIW I’ve experimented with separately changing the background colour and the border colour of the current line highlight using the colour wheels in the appearance preferences, but that doesn’t seem possible.)
- I can’t change the cursor colour - adjusting the appearance for the cursor does nothing in my hands (I can change it’s thickness. Small nit: L&L seem to favour what IMHO are overly tall cursors, including on this forum, which I have to admit I don’t like much.)
I think there might be some confusion over what is expected behaviour here (or maybe I don’t understand what you mean by “origin point”, to me that refers to 0,0 or the cursor before the very first character in the text). What is supposed to happen is that if you are writing in one section of your draft, and you navigate to some other section for a moment to check something, when you return to where you were, you will be taken right back to where you left off. There are a few exceptions, but for the most part that should always be what happens and there is no way to return the cursor to the origin save for ⌘↑.
Wouldn’t ⌘J help here? Do note it is an editor command, it won’t work immediately after clicking on an item in the binder because the keyboard focus will be in the binder. Try hitting ⌃Tab to move the cursor over to the editor, and then the shortcut to jump to the cursor. Normally the cursor will be right in the middle though. Usually the jump command is only necessary if you’ve been passively scrolling.
Naturally, putting the focus in the editor will also activate and reveal the cursor—so if that’s what you mean about it not being visible while working in the binder, that’s just how things work. You can’t type in two different areas of the window at once.
Appearance: General Interface preference pane: Draw border around current line highlights.
It sounds like you’ve been to the right place (Appearance: Textual Marks: Color). Two things of note: the “insertion point” colour is blended a touch, so you might need to pick a colour that is a little “hotter” than you really want. Second note: there is a condition where the software will override the cursor colour, when using Revision Mode. The cursor will take on whatever colour is associated with the current revision level.
