Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore-cursor-position is broken #184

Closed
Bill-MI opened this issue Jun 9, 2016 · 6 comments
Closed

Restore-cursor-position is broken #184

Bill-MI opened this issue Jun 9, 2016 · 6 comments

Comments

@Bill-MI
Copy link

Bill-MI commented Jun 9, 2016

The setting is under org.mate.pluma -> restore-cursor-position and defaults in Ubuntu-Mate 16.04 to enabled. I think most have this same default. Same buggy behavior in Mate 1.14.1 just verified.

  1. Open any text file, I use Caja, hundreds of lines is best to demonstrate the lack of functionality.
  2. Place the cursor well down into the file somewhere.
  3. Close the file, saved, altered or unsaved - it doesn't matter.
  4. Open the file again.
  5. Your cursor should be where you left it. Most the time it is not.

My workaround is use gedit but that's cheating.
Here's what I found that could point to the problem...

If you go to the end of a line and type: (Space)(Backspace)
This makes Pluma think the file has been altered - it hasn't really, of course.
Now, close the Window by clicking "X" or Ctrl+W or Alt+F4.
Answer "Close without saving".
Now it possibly remembers! Fairly repeatable here. Generating that dialog is a factor?

I'm not sure how long it's been since this worked right but surprised no one else misses this feature like I do.

@raveit65
Copy link
Member

I can't really reproduce the issue with mate-1.15.x gtk3 on fedora 24, but maybe this is a random issue, so i will review your PR.

@raveit65
Copy link
Member

Ok, now i see the different :)
With your PR the scrolled window shows the old cursor position, w/o the cursor is at this position but you need to to type the arrow keys to show the position in the scrolled window.
Nice finder ;)

@Bill-MI
Copy link
Author

Bill-MI commented Jul 29, 2016

For the record, cursor position is not outside the display window needing a scroll to see it. Instead, a new cursor position fails to be remembered.

I've adopted a work-around that seems to force cursor position to be remembered for a file:

  1. Open file in Pluma, optionally change something. It doesn't matter, here.
  2. Place your cursor where you want it to be remembered for next time.
  3. Save the file. I use Ctrl+S.
  4. Type: (space) (backspace).
  5. Close Pluma. I use Ctrl+W. Dialog opens, select "Close without saving".

This seems to work 100%. Next time this file is opened, the cursor will return exactly where you placed it. Like it should.

If step 4) is skipped, the cursor position is never remembered and no dialog appears in step 5). Or, if a cursor position was previously remembered, it doesn't update to the new location as it should.

This is very repeatable in Ubuntu-Mate 16.04 with Mate 1.12 or 1.14.

Does anyone know where this data is stored? I tried to find it unsuccessfully.

@raveit65
Copy link
Member

I guess it is somewhere in home folder because i noticed that using pluma as root will never restore the cursor position with your PR.
So, i think that pluma as root in user session can't read/store the info in user home folder.
.....just a theory.

@monsta
Copy link
Contributor

monsta commented Sep 30, 2016

I think it was solved in #191...

@Bill-MI
Copy link
Author

Bill-MI commented Sep 30, 2016

YES. It's fixed in Ubuntu-Mate 16.10 beta 2 which is running Pluma 1.15.2.

The symptoms are different than #191 (see my previous comment here) but it is possible the fix for that scrolling race condition is appearing differently to me. So they may be different results from the same bug.

Based on Pluma 1.15.2 working perfectly, this can be closed. Thanks!

@raveit65 raveit65 closed this as completed Oct 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants