Open brandondrew opened 2 months ago
I think you mentioned a similar kind of behaviour the other day
Hey @brandondrew, sorry to hear that! Let's get to the bottom of this.
sqlite3 ~/Library/Application\ Support/Zed/db/0-stable/db.sqlite 'select path, contents from editors where path is not null or contents is not null;'
? (You need to change 0-stable
to 0-preview
in case you use a preview release) That should give you the path and the contents (if it was dirty) that we savedsqlite3 ~/Library/Application\ Support/Zed/db/0-stable/db.sqlite 'select workspace_id, window_state, window_x, window_y, window_height, window_id from workspaces;'
— are there any rows where the window_height
and window_width
are 0?My hunch right now is that the new feature (saving buffer contents) isn't broken, but that something existing broke and the workspace itself couldn't be saved/restored and thus the buffers are also not restored.
1|||||
3|||||
4|||||
5|Fixed|645.0|25.0|875.0|
6|||||
7|||||
8|Maximized||||
9|Fixed|0.0|25.0|875.0|
10|Maximized||||
12|Fixed|0.0|25.0|875.0|
13|Windowed|0.0|25.0|875.0|
14|Fixed|0.0|25.0|875.0|
15|Fixed|0.0|25.0|875.0|
16|||||4294967302
17|||||
19|||||
20|Fixed|0.0|25.0|875.0|
23|||||
24|||||
25|||||
26|||||
27|||||
29|||||
30|Fixed|0.0|25.0|875.0|
31|Fixed|0.0|25.0|875.0|
32|||||
33|Windowed|0.0|25.0|875.0|4294967300
35|Windowed|0.0|25.0|875.0|4294967297
36|Windowed|0.0|25.0|875.0|4294967298
37|Windowed|0.0|25.0|875.0|
38|Windowed|0.0|25.0|875.0|
39|Windowed|0.0|25.0|875.0|4294967299
40|Windowed|0.0|25.0|875.0|4294967307
41|Windowed|0.0|25.0|875.0|4294967301
42|Windowed|0.0|25.0|875.0|4294967303
43|||||
44|Windowed|0.0|25.0|875.0|4294967305
45|Windowed|0.0|25.0|875.0|4294967304
46|||||
47|||||
50|Windowed|0.0|25.0|875.0|4294967306
51|||||
52|Windowed|0.0|25.0|875.0|4294967310
54|Windowed|0.0|25.0|875.0|4294967308
57|||||
58|Windowed|0.0|25.0|875.0|4294967297
59|Windowed|0.0|25.0|875.0|4294967311
60|Windowed|96.0|114.0|700.0|
61|Windowed|203.0|124.0|700.0|
62|||||
65|Windowed|-1.0|25.0|875.0|
66|Windowed|0.0|25.0|875.0|
67|Windowed|0.0|25.0|875.0|
68|Windowed|0.0|25.0|875.0|4294967297
69|||||
70|||||12884901889
71|Windowed|0.0|25.0|875.0|
3. It showed a mixture of (a) currently open unsaved content, and (b) paths to content that I have probably had open in Zed in the past, but I didn't see anything that looked like a document that could have been lost
Huh, that's odd. The unsaved-buffer contents and the workspace are serialized/restored separately. So the fact that your workspace doesn't show up in the recent projects made me think that it's the workspace that's corrupted, not the contents.
Let me think about this a little more.
What are the config arguments to set to get this to work right? I wonder if it would help to do a sanity check to ensure a config setting is not creating a problem. I'm having trouble getting it to work altogether at this point with or without config settings, so this is of interest to me as well.
Setting to save/restore unsaved buffers:
{"session": { "restore_unsaved_buffers": true}} //default
I feel like I'm going a bit insane here. Walked away for a bit as I cannot get this to work regardless of what I do - and with what appears to be 100% unequivocally correct settings.
I've gone so far as to rm ~/.config/zed/settings.json
(and rm -fr ~/.config/zed
) and I still have the behavior of where it prompts me to save the document and does not restore the documents/session.
This is on 0.153.2
...
Can you record a video of what you're doing? You open Zed, edit a file, then hit cmd-q
to close it?
Precisely @mrnugget, Zed Preview 0.153.3: https://share.zight.com/Kou8wJ7v
Okay, you're using a window without a project. In those windows, storing/restoring unsaved buffers is not supported yet. See my comment here and the whole issue: https://github.com/zed-industries/zed/issues/5258#issuecomment-2259930997
Try opening a project/folder first (cmd-o
) and in that one creating a buffer and then saving Zed with cmd-q
.
Wow, alright... Sorry I didn't see this as associated with that. I tend to use this kind of functionality a lot with Sublime Text and Zed is rather attractive as a replacement in various aspects. Thanks for clarifying and hope that that achieves resolution soon since having projects control this is definitely suboptimal.
@mrnugget Sorry this is somewhat tangential, but is there any reason not to implicitly open a project with every window? In other words, if I type zed ~/.ssh/config
it could open a project where the root is ~/.ssh
. Current behavior (IIRC) is to open in a random (or maybe the first) project despite not belonging to that project's directory.
I'll try to test this later when I've got time (making sure I'm on the latest Zed( and open a separate issue (if none are open already), but the handling of projects seems to affect a lot of different features of Zed, including reopening buffers. I think implicit projects (for lack of a better name) might resolve several surprising or problematic behaviors.
I suppose I could live with an implicit defaults "project" like "scratch" that could work as a catchall - or implicit projects could be contextually created per folder... but this seems like it might be counterintuitive and create some problems. Hmmm.
@brandondrew yeah, I've had similar thoughts. We do something like that too. If you open a single file, sometimes, the workspace is set to that file. Other times it's an untitled workspace/project. But even if we do that, it wouldn't solve all cases, because a lot of people want to hit cmd-n
to open a new window, write something in a buffer, and have that persist — even if you open 5 of those untitled windows. That's how Sublime works and that's how I think it should work in Zed. Just need to figure out how to make it work, but it's a fundamental change that's a bit tricky to get right.
@mrnugget I'm not understanding why my suggestion wouldn't work in the cases you described.
I'm not suggesting that there is only one universal "implicit" project, which I think @ylluminate inferred. Instead, every time you hit ⌘-N without a project open in the same Space/Desktop, or ⌘-⇧-N regardless of any open projects, you would get a new project window, which you could save wherever you want.
I'm not sure if that clears up any confusion.
Sorry, I thought of it both ways (see the second option after the first thought) - and, frankly, neither sits well with me since I think @mrnugget is right that the behavior that is default in Sublime Text, TextMate, and others should in this regard should be emulated since it has become standard/expected and relied on regularly.
Also, although Sublime Text is a very nice editor in many ways, I would recommend TextMate as the model to follow. Although the developer made 2 decisions which IMHO killed TextMate's chances of long-term success (not making it cross-platform, and doing a "big rewrite" that of course took a long time), TextMate got just about everything right when it comes to UX.
I am hoping the Zed is the editor to do everything right, including UX. I think TextMate is a better model to follow than Sublime Text, and far better than VS Code. Zed has already done SO MANY THINGS better than predecessors. It would be a shame to lose the opportunity to surpass all previous editors in every way.
@ylluminate maybe I'm not correctly understanding the behavior he's describing.
@brandondrew you are 💯x💯 right here about TextMate. Ergonomically it was incredible (I still use it some - and I also still use emacs, just not for everything). I don't like how Sublime Text "feels" in many regards... even though it tries to emulate TextMate.
I think we're all talking about the same thing :) I just didn't express myself well. Long story short: we need to persist buffers in windows, even if that window doesn't point to a folder.
I think we're all talking about the same thing :) I just didn't express myself well. Long story short: we need to persist buffers in windows, even if that window doesn't point to a folder.
I 100% agree!
Check for existing issues
Describe the bug / provide steps to reproduce it
I was so happy when Zed began to support bulletproof buffers—which would come back up when restarting, whether saved or not—but this just failed for me when I upgraded to 0.148.0.
In my case (since this was a fairly new feature and I didn't yet trust it to work perfectly) I copied my unsaved buffers into my clipboard, so nothing was actually lost, but it would be really useful to be able to trust this feature to always work.
I don't know whether this is a useful clue or not, but the project that I lost tabs/buffers for was not even in the recent projects dialog after I restarted in the new version of Zed. Perhaps something blew up when attempting to automatically save it, somehow corrupting its record.
Environment
Zed: v0.148.1 (Zed) OS: macOS 14.5.0 Memory: 16 GiB Architecture: aarch64
If applicable, add mockups / screenshots to help explain present your vision of the feature
No response
If applicable, attach your Zed.log file to this issue.
This form would not allow me to include my whole log, so I filtered out lines with
[WARN] Theme
, as I figured that all the warnings about themes were probably not relevant, and there were tons of them since I've installed every theme and looked at all of them.Zed.log