Thread: Customizing cream for local needs: lockfile interlock
Cream is a free, easy-to-use configuration of the Vim text editor
Brought to you by:
digitect
From: BG - B. A. <BAr...@dy...> - 2005-04-04 20:03:17
|
We need to customize Cream to cooperate with interlock and backup files created by a different editor. In order to do this, we need to do extra steps when any file is loaded, and when any file is saved. Previously, we had written a wrapper for this purpose. But we quickly ran into many limitations of using a wrapper. For instance, the extra functionality provided by the wrapper only affects the file opened initially, and does not address using "Open" from within Cream. At this point, I'd like to flesh out a rough plan (which files / functions need to be modified and anything else that might help) to implement such hooks. The hooks need to do at least these jobs: - check to see if a lockfile (basename.jou) exists, and refuse to open the file read-write (or at all) if it does - possibly present a dialog asking if we should still open the file read-only if the lockfile exists - write our own basename.jou when we have confirmed we have access to the lockfile - save the original file as basename.bak - remove the lockfile when the buffer containing the file is closed So, can you help me get oriented? Thanks, Ben |
From: Steve H. <dig...@mi...> - 2005-04-05 01:47:51
|
On Mon, 2005-04-04 at 17:03 -0300, BG - Ben Armstrong wrote: > > We need to customize Cream to cooperate with interlock and backup > files created by a different editor. In order to do this, we need to > do extra steps when any file is loaded, and when any file is saved. > > Previously, we had written a wrapper for this purpose. But we > quickly ran into many limitations of using a wrapper. For instance, > the extra functionality provided by the wrapper only affects the > file opened initially, and does not address using "Open" from within > Cream. > > At this point, I'd like to flesh out a rough plan (which files / > functions need to be modified and anything else that might help) to > implement such hooks. > > The hooks need to do at least these jobs: > - check to see if a lockfile (basename.jou) exists, and refuse to > open the file read-write (or at all) if it does > - possibly present a dialog asking if we should still open the file > read-only if the lockfile exists > - write our own basename.jou when we have confirmed we have access > to the lockfile These three operations are the current implementation for the swapfile "basename.swp". > - save the original file as basename.bak You simply want: set backupext=.bak > - remove the lockfile when the buffer containing the file is closed Again, a native feature of Vim's swapfile. > So, can you help me get oriented? Is there absolutely no way you can use ".swp"? You will save yourself a lot of trouble if you can. If not, this will involve quite a few wrappers around existing code. Some ideas off the top of my head: o You will have to find everywhere Cream opens, reads, writes, and exits and insert a call to a lock file manager. (Maybe just Cream_open(), Cream_save(), and Cream_exit(). Maybe.) o The lock file manager functions (pair) would verify no existing lock file existed on open/writes and removed the existing on buffer close. o Each buffer needs to be managed separately, implying buffer-local vars. o Use Cream's built-in functions for comparing filenames since internally Cream/Vim uses unix format but the path-filename on Windows could be one of several variations. If you fail to compare the buffer and file correctly the lock would fail. o You'll need to manage the swap file of the lock file and think about what happens if there's a crash somewhere in the middle of the process. Vim will handle it but I could imagine quite a bit of overhead in Cream to manage this if it really matters to you. o None of this prevents a plugin from working around this. o An experienced command line user could even accidentally do a :xa! and blow the whole system away. If your users understand the limitations, most of these are no problem. But there might be some complexities not mentioned above. Interesting little project. I would think it's goals could align with Vim's. Maybe you could even sponsor a patch by someone on the Vim list to get the option implemented into the tree by default. I would accept a patch to Cream otherwise. (Or could be hired to write it, too.) -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: BG - B. A. <BAr...@dy...> - 2005-04-05 12:27:57
|
On Mon, 2005-04-04 at 21:47 -0400, Steve Hall wrote: > > - save the original file as basename.bak > > You simply want: > > set backupext=.bak Good. > > So, can you help me get oriented? > > Is there absolutely no way you can use ".swp"? You will save yourself > a lot of trouble if you can. Unfortunately not. The .swp is not just a swapfile. I fear we'll suffer a performance penalty for writing it across to the OpenVMS Samba share. As it is now, .swp is maintained on the local disk, which is lightning fast. Also, we *must* use the file extension ".jou" because the existing editor does, and we can't change that. > If not, this will involve quite a few wrappers around existing code. > Some ideas off the top of my head: > > o You will have to find everywhere Cream opens, reads, writes, and > exits and insert a call to a lock file manager. (Maybe just > Cream_open(), Cream_save(), and Cream_exit(). Maybe.) Yes. I was hoping it was that simple. I'll have to start there and see if that covers everything. > o The lock file manager functions (pair) would verify no existing lock > file existed on open/writes and removed the existing on buffer > close. > o Each buffer needs to be managed separately, implying buffer-local > vars. OK. That's the kind of advice I was looking for, since so far our wrappers have all assumed one file & one buffer per editor session, and only deal with lockfiles entering and exiting the editor. This is going to be a learning experience. :) > o Use Cream's built-in functions for comparing filenames since > internally Cream/Vim uses unix format but the path-filename on > Windows could be one of several variations. If you fail to compare > the buffer and file correctly the lock would fail. Oh, fun. I'm developing on Linux, but deploying on Windows. Thanks for the heads up. > o You'll need to manage the swap file of the lock file and think about > what happens if there's a crash somewhere in the middle of the > process. Vim will handle it but I could imagine quite a bit of > overhead in Cream to manage this if it really matters to you. If our current editor crashes, manual cleanup of the lockfile is needed before you can edit the file again. I expect that's going to be the case too with this system. > o None of this prevents a plugin from working around this. > o An experienced command line user could even accidentally do a :xa! > and blow the whole system away. We don't need to worry about that. I have been told that "protection from obvious accidental mishaps" is all we need to aim for. If you deliberately bypass the lockfile system, you deserve to experience the personal hell you create. :) > If your users understand the limitations, most of these are no > problem. But there might be some complexities not mentioned above. Yup. > Interesting little project. I would think it's goals could align with > Vim's. Maybe you could even sponsor a patch by someone on the Vim list > to get the option implemented into the tree by default. I would accept > a patch to Cream otherwise. (Or could be hired to write it, too.) OK. We'll see what we can do on our own. If I have further specific questions I'll ask here. If we can see a "vimish" way to do things and it is easier than a cream way (or necessary because it can't be done in cream,) we'll go that way. Otherwise, we'll be trying to do everything at the top level, within cream itself. Ben |