After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 349453 - File->Revert resets view to beginning of document instead of keeping line position
File->Revert resets view to beginning of document instead of keeping line pos...
Status: RESOLVED OBSOLETE
Product: gedit
Classification: Applications
Component: file loading and saving
3.14.x
Other All
: Normal normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2006-07-31 16:12 UTC by Guillaume Chazarain
Modified: 2020-11-24 10:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Restore the correct line number and update the display (1.16 KB, patch)
2006-07-31 16:15 UTC, Guillaume Chazarain
none Details | Review

Description Guillaume Chazarain 2006-07-31 16:12:45 UTC
Please describe the problem:
File->Revert sets the line number to the one saved in the metadata. This line number is visible in the status bar, but the text display is actually at the top of the file. Entering something in the text makes the window scroll down to the saved line position in the metadata.

Steps to reproduce:
1. Load a file
2. Set the cursor near the end of the document
3. File->Revert

Actual results:
The file is displayed from the beginning, but the cursor is in the saved metadata position.

Expected results:
The cursor should be on the same line it was before the revert, and the text display should have this line in the center.

Does this happen every time?
Yes.

Other information:
A patch is coming :-)
Comment 1 Guillaume Chazarain 2006-07-31 16:15:59 UTC
Created attachment 69986 [details] [review]
Restore the correct line number and update the display

I'm not sure about the '+ 1' and the interaction with the 'line_pos - 1' in gedit-2.14.3/gedit/gedit-document.c:966
Comment 2 Paolo Borelli 2006-07-31 16:30:53 UTC
(I haven't looked at the patch yet)

Is this really the expected behavior? If you revert, usually the file on disk is different from the one currently in the buffer: does moving to the same line make sense?
Comment 3 Guillaume Chazarain 2006-07-31 17:47:58 UTC
My use case is the following:

o I work on a file with gedit
o at the same time I make a small modification to the file with another tool (indent, nano, svn up, ...)
o I want this modification to be visible in gedit, so I revert the file.

I'd like the scrollbar in gedit to stay at the same position it was before the revert. Of course, as the file changed, it may not be the same exact position. But that doesn't matter, it's roughly at the place I was before.

Another point: that the behaviour of [x]emacs' revert-buffer :-)

And considering that gedit remembers the edit position across a close/open in ~/.gnome2/gedit-metadata.xml I think it should also remember it across a revert.
Comment 4 Boris Burtin 2008-02-16 00:17:14 UTC
Another vote for this one.  Resetting the cursor position gets tedious when viewing and reloading logfiles with gedit.
Comment 5 André Klapper 2012-07-29 10:54:35 UTC
In 3.2:
The file is displayed from the beginning, and the cursor is also set to first line, first character.
Comment 6 Sébastien Wilmet 2015-04-14 10:16:42 UTC
Still a problem with gedit 3.14.
Comment 7 Sébastien Wilmet 2020-11-24 10:00:56 UTC
Mass-closing of all gedit bugzilla tickets.

Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing:

2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3

By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements.

We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.