Tickets :: Comment on [#10] Complex path related issue

Your Email Address
Spam protection	Enter the letters below: __ ______ _____ _____ _____ \ \ / / __ \\| __ \ / ____\|_ _\| \ V / \| \| \| \|__) \| (___ \| \| > <\| \| \| \| ___/ \___ \ \| \| / . \ \|__\| \| \| ____) \|_\| \|_ /_/ \_\____/\|_\| \|_____/\|_____\|
Comment	> I suppose the solution could be one of (or a combination of) the following: > > ---------- > 1) Opening the file > > It should be configurable whether, when editing testdir:TESTFILE.TXT, > the file > is opened as > testdir:TESTFILE.TXT > or as > USRDSK:<ZAY.WORK.TESTDIR.TEST_3>TESTFILE.TXT > > I personally would configure this to be always the latter (physical > path), but > perhaps someone would go for the former. > > Perhaps this should be a VMS-only feature of vim. > > It should also be possible to change this setting per file. For > example, I may > want to open all files using the physical path, except of FOO.TXT, > where I want > to use the logical path. I should be able to define an autocommand > (BufReadPre FOO.TXT) that switches the setting to "logical" when opening > FOO.TXT. > > (As described in comment #2, vim does not allow a BufReadPre autocommand to > change the name of the file to be edited. I think that is a good security > policy, and can be retained. This setting allows one kind of hole into this > policy, but the hole is very reasonable and limited, so it should not > present a > security problem.) > > ---------- > 2) Writing the file > > Again, it should be configurable, when the file is opened as > testdir:TESTFILE.TXT > i.e. using a logical path, how the writing behaves. I see 2 options: > > a) Copy to the first path to which testdir translates. > > As Zoltan described, this is how vim behaves currently. I think > this is not > functionally wrong, strictly speaking, but it can be annoying/surprising. > > In fact, this is similar to using VMS copy: when TESTFILE.TXT only > exists in > TEST_3, and we execute > $ copy testdir:TESTFILE.TXT testdir:TESTFILE.TXT > the file is copied to TEST_1. > > b) Copy over the current file. > > I suppose this is what Zoltan wants. The file should be replaced > in TEST_3. > > Again, this should be configurable as a setting (perhaps global), but > modifiable with an autocommand (per file). > > c) Copy over the first testdir:TESTFILE.TXT (?!). > > This is something to consider. For example, TESTFILE.TXT only exists in > TEST_3. Zoltan opens it in vim. In the meantime, someone creates > TESTFILE.TXT in TEST_2. > > Is there any case when Zoltan may want to replace the file in TEST_2? > > Perhaps not. If not, we should not consider c) an option. > > In the very least, we must consider this scenario in b): the > implementation > of b) cannot be simply to find the first occurrence of > testdir:TESTFILE.TXT > and replace it. It is wrong to assume that the first testdir:TESTFILE.TXT > found when writing is the same as the first testdir:TESTFILE.TXT > found when > opening. > > Note: at work, we use multi-translation logicals like testdir. The first > translation refers to a user directory, the latter to a system directory. > (Is this common elsewhere?) The system directory is not writable. > > Thus, to continue the example above, if my setting was to use b)-style > writing (replace the file), and I edit and write a file in the system > directory, the write will fail. > > But this can be solved by the user: > - detect that the file is opened read-only -> change to a) > or > - try writing b)-style, try/catch e45 or e212 -> change to a) >
Attachment
Watch this ticket