zed
zed copied to clipboard
Don't write .tmp files to ~/.config/zed/
Check for existing issues
- [X] Completed
Describe the bug / provide steps to reproduce it
I've got dozens of temp files like .tmp2kFlv3
in my ~/.config/zed/
directory, presumably containing telemetry entries. Per the XDG specification, they should go to ~/.local/share/zed/
or somewhere else.
Arguably, ~/.config/zed/conversations/
and maybe ~/.config/zed/embeddings/
(whatever the latter is) are no config data either.
Otherwise, I'm thrilled to trying out Zed.
Environment
Zed: v0.119.21 (Zed) OS: macOS 12.7.3 Memory: 8 GiB Architecture: x86_64
If applicable, add mockups / screenshots to help explain present your vision of the feature
No response
If applicable, attach your ~/Library/Logs/Zed/Zed.log
file to this issue.
If you only need the most recent lines, you can run the zed: open log
command palette action to see the last 1000.
No response
Agreed. Going with XDG spec, those look like candidates for ~/.local/state/zed/
actually. While a more recent addition, it's already being used my some applications.
This area is pretty foreign to me, but should we be storing these in a place that actually wipes out the data on restart? What about /tmp
? These are telemetry logs and only exist so that you can open up the telemetry log view and audit what we are collecting, so they don't need to persist, IMO.
If they're only of interest for the current session, that sounds good. Their naming suggests that too. I'm a big fan of applications not polluting persistent directories (/var
& Co). Just make sure you're writing to a subdirectory under /tmp
to keep things neat.
I appreciate the transparency about the telemetry logs. Writing to /tmp
would make it hard to find and audit them so, I think ~/.local/share/zed/
or ~/.local/state/zed/
would be a better fit.
For instance, my favorite terminal emulator stores logs like ~/.local/share/wezterm/wezterm-gui-log-626.txt
and deletes files that are older than one week.
What do you think about ~/.config/zed/conversations/
and ~/.config/zed/embeddings/
? I guess they should go to ~/.local
as well. Some people have ~/.config
under version control or back it up regularly and need to define exclusions for these. On my machine, ~/.config/zed
is already the largest subdirectory after just two weeks of very light use.
N.B. / TL;DR: XDG Base Directory Specification
I appreciate the transparency about the telemetry logs. Writing to
/tmp
would make it hard to find and audit them so, I think~/.local/share/zed/
or~/.local/state/zed/
would be a better fit.For instance, my favorite terminal emulator stores logs like
~/.local/share/wezterm/wezterm-gui-log-626.txt
and deletes files that are older than one week.What do you think about
~/.config/zed/conversations/
and~/.config/zed/embeddings/
? I guess they should go to~/.local
as well. Some people have~/.config
under version control or back it up regularly and need to define exclusions for these. On my machine,~/.config/zed
is already the largest subdirectory after just two weeks of very light use.N.B. / TL;DR: XDG Base Directory Specification
I have my zed
directory, under .config
under version control, and the tmp items have been popping up for me, so I get it. We should definitely make this switch.
I love Zed so far!
My .gitignore
:
.tmp*
zed/conversations
zed/embeddings
I have my
zed
directory, under.config
under version control, and the tmp items have been popping up for me, so I get it.
This is what brought me here 👍🏼
On the more theoretical side you should probably respect XDG dirs for #7015.
There's an argument to be made you could just use the directories crate but it ignores XDG on Mac putting configs in ~/Library/Application Support/bla bla
which is inconvenient for versioning dotfiles. There may be alternative libs that first check XDG then fall back to that.
@JosephTLyons Could temp files be written to a subdirectory as a temporary fix? That would reduce clutter when navigating it and simplify .gitignore
to /.config/zed/*/
.
I think this issue should be kept open as it addresses macOS. The fixes solve the problem for Linux and Windows only.