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.

Sign up for GitHub

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

Jump to bottom

Opt out of scroll position restoration for explicitly-closed files #24394

Closed
axefrog opened this issue Apr 10, 2017 · 8 comments
Closed

Opt out of scroll position restoration for explicitly-closed files #24394

axefrog opened this issue Apr 10, 2017 · 8 comments
Assignees
@bpasero
Labels
feature-request Request for new features or functionality verification-needed Verification of issue is requested verified Verification succeeded workbench-state UI state across restarts
Milestone
September 2018

Comments

@axefrog
Copy link

axefrog commented Apr 10, 2017

  • VSCode Version: 1.11.1
  • OS Version: Windows 10

Steps to Reproduce:

  1. Open a file
  2. Scroll down
  3. Close the file on purpose
  4. Reopen the file
  5. Scroll position is restored from before the file was closed

When I close a file, I'm done with it for now. Next time I open it, my intent is usually different to what it was before I closed it. Probably 90% of the time, I find that the restoration of old scroll positions for files I closed on purpose is more of an annoyance than a help. Note that I do want to restore the scroll position in hot exit scenarios. I simply want my former scroll position to be disregarded if I explicitly close the file.

Is there a setting for this? If not, would it be a lot of effort to add a setting for this? I have a lot of files in my project, and constantly being forced to manually scroll to the top before I can begin editing is annoying.
@alexdima alexdima assigned bpasero and unassigned alexdima Apr 10, 2017
@bpasero bpasero added feature-request Request for new features or functionality workbench labels Apr 10, 2017
@bpasero bpasero removed their assignment Apr 10, 2017
@ivosabev
Copy link

Same issue here, haven't found a single case where the current behavior is helpful.

@ghost
Copy link

ghost commented May 12, 2017 •
edited by ghost

@axefrog @ivosabev Can you guys reproduce this in the latest 1.12.1? It always bothered me too but now it seems that it's working (at least as I want), always positioning the cursor at the beginning of the file. Hope that's a feature and not a bug. 🤞

@axefrog
Copy link
Author

axefrog commented May 12, 2017

@mdalpi confirmed - it doesn't seem to be happening for me anymore either.

@ghost
Copy link

ghost commented May 16, 2017 •
edited by ghost

@axefrog It seems that it was a bug after all, it's back on 1.12.2 😢

@bpasero bpasero added workbench-state UI state across restarts and removed workbench labels Nov 16, 2017
@bpasero bpasero mentioned this issue Nov 24, 2017
Closed
@adorep
Copy link

adorep commented Mar 20, 2018

This behavior should be opt-in and disabled by default.
I often open a file, scroll to the bottom looking for something and close it then.

Now nearly every file i open starts at the bottom instead of the top and in 90% of the times the first thing i do is scroll to the top.

@chriserwin
Copy link

I'm also experiencing this behavior:

Steps to reproduce:

  1. Open long file
  2. Scroll halfway down file
  3. Close file
  4. Reopen file

Result, the reopened file is scrolled to the previous scroll position.

screencast

This behavior is unlike any text editor that I've used in the past. I very rarely want to open a file at the same scroll position, especially after I've been working in other files for a while. It can be disorienting, and frustrating to open a file at a position that doesn't match your current mental map of the file.

Ideally there would be a setting that you could toggle on/off to restore editor state when opening a file. Something like editor.restoreViewStateOnOpen

I'd be happy to take to try implementing this if someone could point me in the right direction. It looks like view state might be restored in the codeEditorWidget's restoreViewState function (here), but I'm not overly familiar with the codebase.

@bpasero bpasero mentioned this issue Aug 31, 2018
Closed
@aviddiviner aviddiviner mentioned this issue Sep 1, 2018
Closed
@bpasero
Copy link
Member

bpasero commented Sep 21, 2018 •
edited

There is now a new setting workbench.editor.restoreViewState to control this. I did not change our defaults. For those that e.g. are not using tabs, closing an editor is nothing special and has no semantic meaning. If I later open a file again, I want it to be where I left off. I recommend to try to use this model, it has a lot less clutter overall.

@bpasero bpasero closed this as completed Sep 21, 2018
@bpasero bpasero self-assigned this Sep 21, 2018
@bpasero bpasero added this to the September 2018 milestone Sep 21, 2018
bpasero added a commit that referenced this issue Sep 21, 2018
@bpasero
fix #24394
27cb886
@bpasero bpasero added the verification-needed Verification of issue is requested label Sep 24, 2018
@bpasero
Copy link
Member

bpasero commented Sep 24, 2018

Verification:
When the setting is enabled, closing and opening a file will reset all view state (cursors, folding, etc). But when switching between 2 tabs, the view state remains (also across restarts).

@mjbvz mjbvz added the verified Verification succeeded label Sep 25, 2018
@mjbvz mjbvz mentioned this issue Sep 25, 2018
Closed
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bpasero bpasero

Labels
feature-request Request for new features or functionality verification-needed Verification of issue is requested verified Verification succeeded workbench-state UI state across restarts
Projects
None yet
Milestone
September 2018
Development

No branches or pull requests
7 participants
@chriserwin @ivosabev @axefrog @bpasero @adorep @alexdima @mjbvz