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

Want lock files #4257

Closed
gdamore opened this issue Oct 13, 2022 · 8 comments
Closed

Want lock files #4257

gdamore opened this issue Oct 13, 2022 · 8 comments
Labels
A-helix-term Area: Helix term improvements C-enhancement Category: Improvements

Comments

@gdamore
Copy link
Contributor

gdamore commented Oct 13, 2022

I frequently make a mistake when using hx that I don't make with vi. That mistake is that I open a duplicate instance of hx on the same file.

This causes me all kinds of grief, because I can occasionally switch to a window running an instance editing an older version of the file. If I then write out content, the resulting data overwwrites what was there.

What I'd like is one, or both, of two different behaviors (could be enabled via opt-in):

  1. When starting hx on a file (or opening a file), create a lock or swap file, and complain if trying to open a file that is already being edited.
  2. Detect when a file was edited out band (stat the file before saving and make sure that the last modified time is not changed from when it was read, for example). This should give a warning, and ask the user whether to write the file anyway, abandon the change and reload from on-disk, or possibly other actions (do nothing, make a backup, etc.)

Sometimes vi/vim are a pain in this regard, but really they are saving my bacon, and I miss this protection from helix. This is a must have feature IMO.

@gdamore gdamore added the C-enhancement Category: Improvements label Oct 13, 2022
@pathwave
Copy link

pathwave commented Oct 13, 2022

There was also some talk about having a helix daemon, in that case opening a file in another instance could instead give a view into the same file (in memory) as a 3rd option

@Ordoviz
Copy link
Contributor

Ordoviz commented Oct 14, 2022

I hate Vim's swap file messages when I just want to view a file. Kakoune doesn't use lock files, but this was never an issue for me, because it detects when a file was modified externally (#1125).

@kirawi kirawi added the A-helix-term Area: Helix term improvements label Oct 15, 2022
@kirawi
Copy link
Member

kirawi commented Oct 15, 2022

#312 will resolve this as well.

@gdamore
Copy link
Contributor Author

gdamore commented Oct 19, 2022

#312 might fix this, if you're using the client/server model. But my thoughts here are:

  1. Do I have to use the client/server model?
  2. What if someone starts another server?
  3. Forcing the solution for this (which should be a small problem to solve) to rely on the client/server (which is almost certainly a much larger architectural piece of work) seems misguided.

So I'd rather see a fix for this sooner.

Btw, for bonus points, it would be kind of cool if helix could detect the presence of a vim swap file too. I still go back and forth (which is kind of brain warping) and in an environment with multiple people (think an /etc/ file on a server) it would be a nice feature to detect when it's likely someone else is working on the same file.

@edrex
Copy link

edrex commented Dec 8, 2022

My take:

Suggest closing this in preference to #1125.

@ardijanr
Copy link

ardijanr commented Sep 26, 2023

I disagree with the server/deamon thing. swap files and history recovery with reloading changed files would solve all of these issues.

@pr2502
Copy link

pr2502 commented Oct 19, 2023

Adding a me2, I've just accidentally overwritten a good chunk of my work by saving a very old buffer from a forgotten window over the current one.

@pascalkuthe
Copy link
Member

This was addressed by using mtime based detection to prevent overwrites and also by making sure writes are atomic so there are no partial write races. An even better solution will be eventually #1125 so closing favor of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-helix-term Area: Helix term improvements C-enhancement Category: Improvements
Projects
None yet
Development

No branches or pull requests

8 participants