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

Feature: Workspace Persistence #640

Closed
bryphe opened this issue Aug 11, 2019 · 4 comments · Fixed by #1703
Closed

Feature: Workspace Persistence #640

bryphe opened this issue Aug 11, 2019 · 4 comments · Fixed by #1703
Assignees
Labels
A-workspace Area: Overall UX, editor layout, tabs/groups/splits etc. E-good-first-issue Call for participation: Good first issue enhancement New feature or request

Comments

@bryphe
Copy link
Member

bryphe commented Aug 11, 2019

I'd like to add the concept of a session to Onivim 2, which would include the following:

  • The working directory the user was in
  • Open splits / window configuration (which buffers are in which editor group)
  • Window size & location
  • Opt-in hooks for various features to persist (ie, like Zen mode)

We'd save this information to a specific location in the user's folder, likely as JSON.

On load, we'd pick up this persisted info and restore the user's workspace / session.

Related:

@tcoopman
Copy link
Contributor

We'd save this information to a specific location in the user's folder, likely as JSON.

Do you mean, save this in the workspace folder, or in the user's config folder?

@raguay
Copy link

raguay commented Aug 13, 2019

I would rather save this at the top of the project directory. Just like VSCode and Sublime Text does. That way, I can save it in my repo, wipe and reinstall from the repo and still have the same configuration for editing the project.

@despairblue
Copy link
Contributor

I would rather save this at the top of the project directory. Just like VSCode and Sublime Text does. That way, I can save it in my repo, wipe and reinstall from the repo and still have the same configuration for editing the project.

Usually that just ends up in the gitignore file since not everyone on the team uses the same settings or even editor.

I like how atom does it which saves it somewhere in the config directory.

@CrossR CrossR added the enhancement New feature or request label Aug 13, 2019
@glennsl glennsl added the E-good-first-issue Call for participation: Good first issue label Oct 26, 2019
@glennsl
Copy link
Member

glennsl commented Oct 26, 2019

Labeled good-first-issue for the basic persistence and restore logic for simple properties like working directory and window size/location. The rest requires a bit more know-how, but can also be added later.

@glennsl glennsl added the A-workspace Area: Overall UX, editor layout, tabs/groups/splits etc. label Nov 18, 2019
@glennsl glennsl self-assigned this Apr 27, 2020
glennsl added a commit that referenced this issue May 5, 2020
…and window state (#1703)

* add Filesystem.getStoreFolder

* expose Filesystem.getOrCreateConfigFolder

* add definition of Persistence "items"

* add definitions for Global store

* add store instantiation

* add logic to write to file

* trigger on state change

* add Workspace store

* persist workspace store on move and resize

* remove cliOptions from StoreThread in favor of explicit arguments

* move Cli from Core to bin_editor

* fall back to persisted working directory if not specified on the command line

* read store file on instantiation

* add get function to retrieve an item from the store

* make state.workspace non-optional

* set window size and position initially based on persisted workspace settings

* post-rebase fix

* fix warning

* add interface

* refactor

* special case hash for "global"

* fix window positioning

* add bool codec

* persist maximized window state

* cache store file path

* use Luv for non-blocking I/O on persist

* fall back to Documents instead of working directory

* move Persistence infrastructure to Core

* forward store infrastructure functions to builtin stores

* refactor store API for great good

* simplify builtin store API

* fix tests

* handle missing store path more gracefully

* Switch to new Dir API

* Use forked dir for now

* Update lockfiles

* Formatting

Co-authored-by: bryphe <bryphe@outrunlabs.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-workspace Area: Overall UX, editor layout, tabs/groups/splits etc. E-good-first-issue Call for participation: Good first issue enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants