I got around to quite a bit of experimenting today, and I am getting inconsistent results. I apologize, but I didn't set up a case testing scenario to clearly and unambiguously sort out the behavior.
My test-beds for gvim --clean -R filename and gvim filename in Powershell. In Windows 10 the user interface was used. 1. & "C:\Program Files\Vim\vim82\gvim.exe" --clean -R C:\Users\johnk\atestfile.txt (powershell) 2. & 'C:\Program Files\Vim\vim82\gvim.exe' C:\Users\johnk\atestfile.txt (powershell) 3. Gvim 8.2 icon>> Click>> File>> Open...>> select file>> Open 4. Gvim Read only 8.2 icon>> Click>> File>> Open...>> select file>> Open 5. Open File Browser on Directory>> select file>> left click>> mouse right click>> Edit with Vim I did find differences in behavior ( e.g. changed the modify time stamp or didn't) when: 1. Different ways were used to open with the full script set 2. Different directories were used. 3. Difference between Powershell command line and windows interface behavior 4. Behavior tended to be consistent in streaks and then sudden flip. 5. Various scenarios tended toward modifying the time stamp more than others. 6. Using --clean -R touched the file sigificantly less often, but there were scenarios in which it always touched the file. Only the & "C:\Program Files\Vim\vim82\gvim.exe" --clean -R C:\Users\johnk\atestfile.txt had the reduced script set. The Gvim Read only 8.2 icon seemed to use the same scripts as most of the other Gvims. The reduced set of --clean -R scripts as reported by *:scriptnames* were: - 1: C:\Program Files\Vim\vim82\defaults.vim - 2: C:\Program Files\Vim\vim82\syntax\syntax.vim - 3: C:\Program Files\Vim\vim82\syntax\synload.vim - 4: C:\Program Files\Vim\vim82\syntax\syncolor.vim - 5: C:\Program Files\Vim\vim82\filetype.vim - 6: C:\Program Files\Vim\vim82\menu.vim - 7: C:\Program Files\Vim\vim82\autoload\paste.vim - 8: C:\Program Files\Vim\vim82\ftplugin.vim - 9: C:\Program Files\Vim\vim82\indent.vim - 10: C:\Program Files\Vim\vim82\scripts.vim - 11: C:\Program Files\Vim\vim82\ftplugin\text.vim The additional scripts for the other gvim choices were picked from: - C:\Program Files\Vim\_vimrc - C:\Program Files\Vim\vim82\*.vim (and subdirectories) Since there are over a thousand .vim files in the mentioned subdirectories, one can always find what was actually loaded with *:scriptnames* The other day I tried some debugging without much success I wasn't able to narrow things down much. I don't know enough to know how to drill down with this, maybe some of you might do better> - :set verbose= (runs from 0 to 15) - :set verbosefile=filename - :breakadd filename (script) - :debug CommandNmae - :debug function(arg) Possible causes of the problem behavior may be: 1. due either to Windows or Gvim 2. behavior of ".' as apposed to $HOME 3. script errors such as indent .vim file not being found (not seen except in logs) 4. who knows? Only my guesses. But I am willing to bet that when the reason is found it will be Windows. I have seen several cases of sloppy programming during this little sojourn. For example, 3+ color controls for Powershell including terminal color config, local categorical color control, text types by color, patched modifications of particular behavior, and system color settings with apparently independent uncoordinated and unsystematic behavior among all of them touching Powershell. Now I am an old fogey and I am near my limit. In bringing Windows up to date I had to install the nefarious Microsoft Edge, which is driving me nuts. So in a few days I am going to roll back my computer and delay installing Microsoft Edge until at least October before Microsoft puts the arm on me. Unfortunately after that I will not have an untouched vanella Windows and Gvim environment to test in. So excuse me if I fade into the woodwork at that time. Sincerely, JS On Friday, August 14, 2020 at 6:47:32 AM UTC-7 Tony Mechelynck wrote: > On Fri, Aug 14, 2020 at 1:36 PM John Sellers <johnks...@gmail.com> wrote: > > > > This is happening on my new month year old computer as well as my 10+ > year old computer. > > > > The behavior is exactly the same on both computers when using Gvim to > open a .txt file. (I have not checked other kinds of files). > > > > While looking at the file in a Windows explorer directory in detail > mode, I see the modification date updated to the present moment at the > instant I open the file. > > > > This happens when opening the .txt file by: > > :r filename <enter> > > > > or by using the menus: > > File>> Open...>> Edit file>> select filename>> Open > > ----------- > > > > > > I double checked the behavior by Updating Windows and uninstalling my > 32x Vim install and re-installing a 64x Vim install. I also update Windows > 10 to the current version. > > > > I again saw exactly the same behavior. (Please, a few of you try this > and report the outcome to my current thread about the issue in VIM_USE, and > I will take those and update VIM_DEV.) > > > > Here are the details of my installation of Vim and Windows 10, however > it seems to happen on some different recent versions of Vim and Windows: > > > > GVIM---- > > Signed 64 bit installer > > gvim_8.2.1444_x64.exe > > :version > > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 13 2020 22:02:15) > > MS-Windows 64-bit GUI version with OLE support > > Included patches: 1-1444 > > (full version less .bat files) > > > > WINDOWS 10 Home---- > > 2020-08 Cumulative Update for Windows 10 Version 2004 for x64-based > Systems (KB4566782) > > Successfully installed on 8/14/2020 > > 2020-05 Microsoft Edge Update for Windows 10 Version 2004 for x64-based > Systems (KB4559309) > > Successfully installed on 8/14/2020 > > 2020-08 Cumulative Update for .NET Framework 3.5 and 4.8 for Windows 10 > Version 2004 for x64 (KB4569745) > > Successfully installed on 8/14/2020 > > Windows 10 up to date - 8/14/2020 > > IIUC, gvim 8.2.1444 is the latest version. > > Does it also happen if you type the following in a Dos Box? > > gvim --clean -R filename.txt > > where --clean (with two dashes) means "use only the default setup, as > set by defaults.vim; and -R (with only one dash) means "readonly". > > If it doesn't, it could be your vimrc, or some third-party plugin, or > (if it exists) a "system vimrc" (whose exact directory and file names > are listed near the middle of the output of :version) > If it happens even in this controlled environment, I don't know what > it is; maybe Windows? I cannot reproduce the problem on Linux, but you > aren't the first one bitten by it on Windows. > > Best regards, > Tony. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/4e27eb6d-03ec-4070-b6e1-aa45dc58c658n%40googlegroups.com.
