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

File watcher breaks when using Helix editor #2131

Open
LatjoLajbin opened this issue Oct 1, 2024 · 5 comments
Open

File watcher breaks when using Helix editor #2131

LatjoLajbin opened this issue Oct 1, 2024 · 5 comments

Comments

@LatjoLajbin
Copy link

Running d2 with filewatching breaks as soon as a save is performed, as helix creates and removes a backup file in case of crashes.

Found a similar report in the discord where the user was prompted to make a github issue, but I'm making this since I couldn't seem to find one.

OS: Windows
Shell: PowerShell
Editor: Helix
Installed via: Scoop (v0.6.7)

Wondering if this is related to the 16 milliseconds of event catching in d2cli/watch.go? It feels weird that it's receiving the file system event REMOVE and then immediately tries to ensure that it's being filewatched.

{11631616-B09F-4312-9FD5-925D3D9FCF3A}

There's a discussion in the helix repo regarding a similar issue in Hugo, where it was solved in Hugo by adding .bck files as file type exceptions.

helix-editor/helix#11715
gohugoio/hugo#12856

@alixander
Copy link
Collaborator

oo interesting, thanks for the legwork researching this

@alixander
Copy link
Collaborator

i installed helix and tried to reproduce but could not. is there a setting you're using to turn on backup files?

Kapture.2024-10-01.at.12.42.50.mp4

@LatjoLajbin
Copy link
Author

Not really, no. if I read it right, the error shows up in os.Stat(path) [go.watch:356]. Does powershell do something different than zsh when trying to find a file? I don't have wsl setup right now to test with on the same machine...

I only found out about the backup file writing through this issue, but my understanding is that it's a baseline for most editors that safeguards against file corruption if the editor crashes during write.

{0F49669C-98AC-4076-BE37-9B642D9CB28D}

@alixander
Copy link
Collaborator

i think related to #9

I wonder if this issue is circumvented if we just do atomic writes

@alixander
Copy link
Collaborator

Let's see in the next version if this still is an issue: #2141

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

2 participants