How to save cursor position in Writer?

English
,
#1

How can I get the cursor to remember the last position in a saved .odt document? It was working fine yesterday. After restarting my computer and opening the file today, the cursor now goes to the top of the document and not to the last place where I typed (the last cell of a table in Writer).

Using LibreOffice Version: 6.1.1.2 (x64) on Windows 10

I’ve already done the 2 steps listed here:

The 2 steps are:

  1. File > Properties. In the properties window, check Apply User Data and click Reset Properties
    Apply User Data was already check marked.

  2. Tools > Options. In the options window, under LibreOffice, click user data, enter a first name in first text box.

I already had a first and last name entered. I removed the first/last name and reentered it.

The document is saved as .odt and never was anything but .odt

I copied the text to a new document and saved that. The cursor still does not go to the last position.

I already closed LO and restarted it.

Any other suggestions? Is this a bug?

Open to last position? (Writer 7.3.6.2 Linux)
#11

Seeing as others are having the same problem, I thought I’d let everyone know that I still have the “bug” even after following all the directions at How to Save the Last Cursor Position in LibreOffice Writer - libreofficehelp.com.

I’m the only one that works on the document, on my own Windows 10 computer.

When opening the document, the cursor is always at the top (above the table) even though when I saved the doc, my cursor was in the last cell of a 2-column table at the bottom of page 51. I still have to use the workaround to type Ctrl + End to move quickly to the end of the document.

Version: 7.3.2.2 (x64) / LibreOffice Community
Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0
CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

#12

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.)

#21

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.

1 Like
#22

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/

#2

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.

#3

I read the summary before posting. The directions at the link do not work for me.

#4

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.

#5

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.

1 Like
#6

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)

1 Like
#8

@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”.

#9

@ajlittoz:

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.

#10

@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.

#13

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

1 Like
#14

tdf#141586 describes the history of the problem, its reasons, and links to a few related bugs with additional data bits.

1 Like
#15

Shift+F5 does not take me to the last saved cursor position. It does nothing.

#16

@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.

#17

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?

1 Like
#18

Yes, it’s there in the See Also :slight_smile:

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 :slight_smile:

1 Like
#19

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)

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.