[Feature Request]: file locking, prevent double-editing

[mralusw]

What feature would you like to see?

Even nano has some mechanism to prevent editing the same file from two different processes. Combined with lack of window/tab support, and the suggestion to use the window manager for that (without client/server support), it's a double whammy.

[tosch42]

I don't quite understand your complaint. vis allows you to edit the same file multiple times, yes. But if you want to save your changes, you get a warning that tells you that the file already exists, thus, not overwriting your previous changes. That's basically the behavior most editors (like vim or nano) have. They also don't protect the open file from being overwritten by a third-party process.

[mralusw]

If I try to open the same file in two different vim instances, there will be a swapfile conflict and a warning (upon opening). nano has some similar mechanism.

It appears vis has some mechanism to keep track of... the previous version of the file when it was last saved? Or the previous date? Both? I'm not sure what it has, because with two running instances of vis and a touch command from a different shell I quickly got into a situation where neither vis instanced was willing to save without w!. Even with repeated w!.

Now, I wouldn't mind normally, but since there is no client / server mechanism, and since you advise using the window manager's features for tabs / panes, it seems like one can easily get into some nasty situations. It would be better to detect concurrent editing when opening a buffer, not when attempting to save.

[Disonantemus]

I also would like that feature!, that *does not allow to open same file again with another instance. Is not enough to get a warning on saving, because I use vis everyday with tmux and sometimes happens to me, then get a warning, and is annoying, because I need 2 save with another name and then make a diff to update a file and delete the other one.

Maybe can be a enabled in visrc.lua, but I think should be default. I don't understand the reasoning to allow working 2 or more instances with the same user/machine.

I'm happy using tmux as "window manager" with tabs and panes, I don't understand why there are internal commands like: split, vsplit.

The alternative to me, If you have 2 or more instances with same file, every time there is a change, update in the other ones, to be in sync, maybe is more work to do this, also can be enabled in visrc.lua.

I did ticket #1141 on December, and was closed as "not planned", I hope now gets more attention.

[mcepl]

I don't understand the reasoning to allow working 2 or more instances with the same user/machine.

I see many reasons why I want to have the same file opened multiple times, but of course it would be nice if only one document was R/W and all others were just R/O.

[rnpnr]

I don't think it makes sense for vis to have a mode where you can't edit the in-memory view because you have the file open in another instance.

Synchronizing between different instances is non-trivial, I haven't looked into other editors in detail but I suspect its exactly as Tom said above. If you aren't auto saving the file back to disk when one editor loses focus then you need some way of keeping the in memory views synchronized; hence the need for a server-client architecture.

The auto-saving version is also not good for multiple reasons for example what do you with the undo-history in the second instance when the first instance saves the file? If you reload the file in the second instance then none of the history will line up anymore. But just dropping the history is not really acceptable either.

As it stands I think the current behaviour is fine. Someone could submit a patch warning on file open instead of when trying to save and I'll look at it.

I did ticket #1141 on December, and was closed as "not planned", I hope now gets more attention.

It was closed as a duplicate of a different issue. Please read the comments instead of demanding things of people who are volunteering their time.

[fischerling]

As it stands I think the current behaviour is fine. Someone could submit a patch warning on file open instead of when trying to save and I'll look at it.

This is probably not to hard to implement in Lua.
Subscribe to FILE_OPEN events and create a lock file if there currently is none.
If a lock file already exists print a warning and/or ask for confirmation.
Remember if a lock file was created in order to to remove it upon FILE_CLOSE.

[Disonantemus]

It was closed as a duplicate of a different issue. Please read the comments instead of demanding things of people who are volunteering their time.

I did read #968 at the time, that went to: Multi-file support is not yet well supported and I don't want Multi-File support or sync.
I know is volunteering work and I'm very grateful for that, I'm no programmer and did this account only to give some feedback to software that I like, and I use vis everyday. Maybe my English is not so good, because is not my 1st language.

I just say that, as it is now, vis allows double editing, and is annoying to me (because I don't want to do a diff every time that happens).

---

Maybe and easy way is some of this, that was already suggested:

• Only allow R/W to 1st instance, and later ones, just read only. @mcepl
• A warning when opening same file again (not later when writing). @rnpnr @fischerling
• And if there are people that want as it is now, just have a configuration flag to change in visrc that please both sides, with any default.

[mralusw]

This is probably not to hard to implement in Lua. Subscribe to FILE_OPEN events and create a lock file if there currently is none. If a lock file already exists print a warning and/or ask for confirmation. Remember if a lock file was created in order to to remove it upon FILE_CLOSE.

First of all, is this currently achievable through lua code?

Otherwise, that's one job of Vim's .swp file. Of course, you would need an option to define which directory to save them under (i.e. the vim directory option), because presumably some users would want those dont-call-them-swapfiles in the buffer's directory and some under some centralized folder. And the centralized folder better not be fixed in the user's home, because if the user runs a persistent-USB linux distro, or has their $HOME on a network FS, they don't want the editor to hang when opening a file (e.g. I would want the dont-call-them-swapfiles in $XDG_RUNTIME_DIR).

If vis stores the not-yet-saved edits for each buffer in some data structure in memory (it must, otherwise there would be no undo), it could use the dont-call-them-swapfiles to persist those unsaved edits every, I dunno, 200 characters typed or after 4 seconds of inactivity (let's call them updatecount and updatetime). Then vis would gain the ability to recover after crashes (and you might as well call them swapfiles).

[rnpnr]

First of all, is this currently achievable through lua code?

Yes? Why not?

swapfiles

This is nowhere near what fischerling is suggesting. For one it would require no new C code. I am going to need quite some convincing when your 400 (more?) line patch arrives in my inbox to solve something that boils down to PEBKAC.

If you are experiencing crashes please report them so that they can get fixed. We won't be adding any code that serves no purpose besides working around bugs.

[mralusw]

swapfiles

This is nowhere near what fischerling is suggesting. For one it would require no new C code. I am going to need quite some convincing when your 400 (more?) line patch arrives in my inbox

Yes, I expected nothing more from vis, don't worry about preserving its reputation...

to solve something that boils down to PEBKAC.

I think you're referring to the potential trashing of data when multiple processes edit the same file, which is the subject of this issue. I've stated in the beginning why this is more likely in vis, and also that other editors tend to prevent it. Maybe creating less fertile ground for PEBKAC would be a more appropriate take-away?

If you are experiencing crashes please report them so that they can get fixed

This is interesting, because you seem unaware that crashes happen for various other reasons besides editor bugs. Most frequent: power goes down. Also: editor getting killed due to OOM or sysadmin action, OS doesn't wake up from sleep properly, NFS / SSHFS hangs, and many others.

We won't be adding any code that serves no purpose besides working around bugs.

It may sound controversial, but a real editor cares about user's files more than it cares about its own design purity. Also, most editors acknowledge that crashes do happen and take a "no-fault" approach regarding crashes.

In any case, this should be an entirely separate issue. I wasn't even going to bring it up. But since creating lockfiles (where would they go, BTW?) was brought up, I thought I'd mention the potential to make them more useful.

[fischerling]

I hacked a simple Lua plugin using lock files: vis-lockfiles.

Anyone interested is welcome to contribute.

[fischerling]

swapfiles

This is nowhere near what fischerling is suggesting. For one it would require no new C code. I am going to need quite some convincing when your 400 (more?) line patch arrives in my inbox

Yes, I expected nothing more from vis, don't worry about preserving its reputation...

I have no idea what reputation you are talking about.

to solve something that boils down to PEBKAC.

I think you're referring to the potential trashing of data when multiple processes edit the same file, which is the subject of this issue. I've stated in the beginning why this is more likely in vis, and also that other editors tend to prevent it. Maybe creating less fertile ground for PEBKAC would be a more appropriate take-away?

The goal of vis is not to be the most convenient and feature complete editor out of the box.

All in all I do not understand your attitude.
If you want other people to do voluntary work for you you should definitely be less demanding and telling them that there project is worse than anything else.

If you want a different experience than vis and do not want to invest into it, simply use one of the plenty editors out there, that do what you expect.

[mralusw]

If you want a different experience than vis and do not want to invest into it, simply use one of the plenty editors out there, that do what you expect.

I actually like vis to some degree (it's been adopted by oasis linux incidentally). It personally think it's missing some "real editor" checkboxes; but some might be easy to implement.

For one it would require no new C code. I am going to need quite some convincing when your 400 (more?) line patch arrives in my inbox

I have no idea what reputation you are talking about.

^^ Inherent resistance to adding basic functionality to the editor. I've seen this in... other projects. For example, the comment above is a reaction to the mere idea of adding some form of crash recovery. As a counter-point , in #130 there's talk of implementing client / server (while avoiding simple "screen real-estate" management, which is a core feature of any editor after ex).

All in all I do not understand your attitude. If you want other people to do voluntary work for you you should definitely be less demanding and telling them that there project is worse than anything else.

I care more about design decisions / roadmaps. I'm also writing & contributing to OSS, so I can perfectly understand that dev bandwidth is limited. I hope to find some time to look more closely at vis code soon.

The goal of vis is not to be the most convenient and feature complete editor out of the box.

That's fine. Some issues are meant as enhancements / proposals, some are meant as bug reports. How the reporter and how the devs view the issue can differ. But for some resemblance of objectivity, there is precedent and there are peer editors to compare against.

[rnpnr]

missing some "real editor" checkboxes
[...]
(while avoiding simple "screen real-estate" management, which is a core feature of any editor after ex).
[...]
there is precedent and there are peer editors to compare against.

You are writing as if the design of text editors is a solved problem. The reason I was drawn to vis in the first place is because it made no such assumptions. Why limit ourselves to doing the same thing that everyone else already does? The way you write makes me think that vis is not the editor for you. That is OK. We make no claims of wanting to be an everybody editor.

[mralusw]

You are writing as if the design of text editors is a solved problem. The reason I was drawn to vis in the first place is because it made no such assumptions. Why limit ourselves to doing the same thing that everyone else already does? The way you write makes me think that vis is not the editor for you. That is OK. We make no claims of wanting to be an everybody editor.

For sure it's not, and I've used many editors, from joe, nano, micro, to *emacs, *vim, kak and helix. And others...

I do think it's important to check some boxes (like avoid losing data...). It would furthermore be nice to use vis as a default editor in "lite" / minimalistic scenarios (the way it's packaged in Oasis Linux for example). It's... actually a surprisingly powerful editor for its size [1]. But that might mean bowing to some precedent, and I understand you may not want it.

In any case, as far as this issue goes, I'm working on @fischerling's plugin. It might work or not, I'm not sure yet (e.g. I don't know if a plugin can cancel a pending :e command from a subscribed FILE_OPEN event without exiting the entire process). We'll see.

---

[1] An up-to-date line count (including help files, translations etc — so not really fair). It's funny how for vim a single xargs maxes out the OS argv limit, hence the need for awk.

fd -t f . /S/vis/ | xargs -d'\n' sh -c 'wc -l "$@" | tail -1'  | awk '{ sum += $1 }; END{ print sum }'
# 49886
# same for vim
# 1922926

[fischerling]

Can we close this, because vis-lockfiles can handle the abort case using 352ee07?