See tdf#151427.
Somebody just today opened that bug.
Anybody creating a bug report based on a discussion here, please post a link to it.
BTW When I tested today, it was the first time that the cursor in the re-opened file was neither correctly placed at the position it had when saving, nor at the beginning or end of all text. It jumped up in an arbitrary erroneous position. (Feeling baffled I did not yet comment on the bug report adding this experience.)
As of min-Jan 2023 this is still a very annoying bug. See https://bugs.documentfoundation.org/show_bug.cgi?id=141586#c18
I’m running Version: 7.4.3.2 / LibreOffice Community.
As I find this a particularly useful feature – I have a lot of large documents – I’ve gone back to LibreOffice version 7.2.7.2, which is apparently the last release in which this worked properly. Last saved cursor position is working fine now, so I’ll stick with 7.2.7.2 until I see the bug has been fixed.
To download a previous LibreOffice version, go to:
https://downloadarchive.documentfoundation.org/libreoffice/old/
I copied the text to a new document and saved that. The cursor still does not go to the last position.
In your given link you should also read the Summery!
Summary
This is how you can enable Writer to save the last cursor position in LibreOffice Writer. However, please note that you have to do it for each document if you want this result. There is no global option I found which can set this in the LibreOffice Writer profile.
I read the summary before posting. The directions at the link do not work for me.
A work around that will get me to the end of my table and to the 1st column of a 2-column table:
Type Ctrl + End to move quickly to the end of the document. Then Ctrl + arrow up 2 times to get to the 1st column of a 2-column table.
It is only this one document that doesn’t work correctly. I have other documents with tables that do take me to the last position typed.
Years later the problem persists, but only in Writer and then again not in every document. Sometimes Writer saves the cursor position and returns to the exact same place as I left off. In other documents it does not save and opens with the cursor placed at the beginning of line 1. The documents are very similar so I cannot figure out why it works in one but not in the other. I have of course tried all procedures and remedies mentioned above.
However, in the malfunctioning documents I have noticed a peculiar behaviour: it almost saves the cursor position. If I save the document with the cursor on line 5 page 1, it reopens with the cursor on exactly the same place on line 5 page 1. But if I save the cursor on line 20 page 2 it reopens with the cursor on line 15 page 2. And should I save at the beginning of page 3, it reopens with the cursor at page 9! Trying to save later in the document, the cursor reopen at the very beginning of the document.
I am using version LO 7.3.6.2 on the latest stable Ubuntu Linux 22.04.
Unchanged imo:
The stored Last Position applies to the user who stored. More precisely: to the user registered to the user profile active during last storing.
If you want to break this, you should set a bookmark at the respective point. Such bookmarks can be empty,and may be set for many authors under chosen IDs. They are easily removed if no longer needed.
Please tell me if I’m wrong.
shortTextWithEmptyBookmarkForLuppToContinue.odt (27.9 KB)
@Fred193
Shame that the problem still persists, but this is in no way a solution to it. Please, abide by this site rules. Repost as a comment, then delete your “non-answer”.
You sure it’s a persisting problem?
I didn’t state this explicitly, but actually assumed, the user @Fred193 re-opening this old thread having slept more than three years, had stored the file under a different user profile.
Seen this way my “non-answer” can’t be a solution assuming the bug behind the originally (more clearly) reported issue was meanwhile fixed. I could offer the obvious workaround for what I thought was tried to achieve. This isn’t a “solution”, of course, if there is a persistent bug - and only a bugfix could be in this case.
If you have additional information concerning such a bug, please point to it.
@Lupp: my comment was not targeted at you. It seems we posted simultaneously (yours being just a bit earlier than mine) and you appeared before me, letting think I answered you.
I edited my comment, making explicit I address @Fred193. Word “persists” was in his “non-answer”. Apologies if I offended you. I know you’re familiar with the rules.
Have you tried Shift+F5? It should take you to the last saved cursor position, even if no name is entered in Tools > Options > LibreOffice > User Data
tdf#141586 describes the history of the problem, its reasons, and links to a few related bugs with additional data bits.
Shift+F5 does not take me to the last saved cursor position. It does nothing.
@oconomowoc: you wrote once:
Your problem could be some very specific corner case, which would require a sample document in a proper bug report. Without that, your case can’t be helped.
There is also the new report tdf#151427. I personally don’t feel much annoyed by this bug, but I took the opportunity to test for it with my V 7.4.1 and a bug was clearly reproducible with a new file. Actually the bad position wasn’t at the beginning of the text now (and also not at the end), but at a first arbitrary, but then stable place. This may actually be a new bug?
Yes, it’s there in the See Also 
Maybe. I ~often come across reports around this matter, and sometimes do something about some of them (when I can find a distinct pattern). That’s why I know how broken by design our position restore implementation is.
But to allow to repro, the bug needs perfectly clear steps - you could see how much is involved in the problem: the screen size, window size, view mode (single/multiple pages), CPU (and so layout time), …
Usually a test document, precise description, and a screencast could be a start
Anyhow the “new report” is more of a rant.
I am not the founder of a club fostering unneeded automatisms with dark background. Somebody just wanting to append something now and then to a text body has the Ctrl+End functionality. Somebody actually *editing a document again and again will need bookmarks at more than one position…
A feature to create an empty bookmark named based on the users shorthand (“initials”) combined with a date-time (ISO format hopefully) should be much more useful than the conceptually complicated and obviously error-prone automatism discussed here.
You may check the attached to see in detail what I mean - and how to implement it with simple user code in Basic (for frequent use placed in the local Standard library, of course, and bound to a keyboard-shortcut).
automatedBookmarking.odt (30.4 KB)
Shift+F5 is supposed to take you to the last edit position (which normally involves cursor). It works in my Linux version 7.5.3.2. (Be sure F5 doesn’t require Fn key, like in my case.)
The shortcut corresponds to “Restore editing view” command (Tools-Customize-Keyboard) and you could try/add a different shortcut. I am using Shift-Delete.
This seems to be related to re-occurring issues. The unbroken default functionality seems to try to open a writer document at the position where the user now opening it last had placed the view cursor.
Even a single user, however, may want to choose one of a couple of positions where he(f/m) recently worked. To be able to do so, he would need to set bookmarks automatically given a name referring to the current user (more precisely: the user registered to the currently open user-profile) and the current date-time as well.
This may sound a bit complicated, but it can be done by simple user code which may be assigned to a keyboard shortcut or to a different trigger (toolbar area, button action).
I suppose (but didn’t test) the routine can be called by an onDocumentGoingToBeClosed event.
Surely it’s extremely simple to navigate using bookmarks, and also to remove those no longer being needed.
The code:
Sub createUserNamedDTstampedSinglePositionBookmark(Optional dummy)
cDoc = ThisComponent
If NOT cDoc.supportsService("com.sun.star.text.TextDocument") Then Exit Sub
REM hard-coded names
Const dataNode = "/org.openoffice.UserProfile/Data"
Const useAsID = "initials"
REM format strings
Const longDTformat = "YYYY-MM-DD_HH:MM:SS"
Const shortDTformat = "YYYYMMDDHHMMSS" REM preferred by my current camera, e.g.
REM Assumed preferrences
Const dtDelim = "_" REM inserted between user ID and dat.
Const bookmarkStart = False
cCtrl = cDoc.CurrentController
cSel = cCtrl.Selection
If cSel.Count>1 Then Exit Sub
REM Bookmark shall point to a single position. User should define it unambiguosly.
insPos = IIf(bookmarkStart, cSel(0).Start, cSel(0).End)
newBm = ThisComponent.createInstance("com.sun.star.text.Bookmark")
newBmN = simplePropertyValueFromRegistryModificationsXcu(dataNode, useAsID)
newBmN = newBmN & dtDelim & Format(Now(), longDTformat)
newBm.Name = newBmN
cText = insPos.Text
insCur = cText.createTextCursorByRange(insPos)
cText.insertTextContent(insCur, newBm, False)
End Sub
REM Thanks to the documents by Andrew Pitonyak I could easily code this needed helper:
'
Function simplePropertyValueFromRegistryModificationsXcu(pNodePath As String, pPropertyName As String) As Variant
simplePropertyValueFromRegistryModificationsXcu = ":err:"
On Local Error Goto fail
Dim structNode, providerSrv
Dim arguments(0) As New com.sun.star.beans.PropertyValue
Const providerSrvN = "com.sun.star.configuration.ConfigurationProvider"
Const structNodeN = "com.sun.star.configuration.ConfigurationAccess"
providerSrv = createUnoService(providerSrvN)
arguments(0).Name = "nodepath"
arguments(0).Value = pNodePath
structNode = providerSrv.createInstanceWithArguments(structNodeN, arguments())
simplePropertyValueFromRegistryModificationsXcu _
= structNode.getPropertyValue(pPropertyName)
fail:
End Function