VIM question: I think the "file is out of date, reload?" mechanism doesn't work if the file is loaded read-only...

[Kenny McCormack]

VIM question: I think the "file is out of date, reload?" mechanism doesn't
work if the file is loaded read-only...

Say I have a file loaded in two different GVIM windows (under Linux). In
one of the windows, I have the "read-only" flag set (in fact, I do this by
starting gvim originally with "view"). In the other window, it is loaded
normally (writable). The general idea is that the first window is only for
looking, while I do my editing in the second window. Note: To be clear,
these are completely separate instances of GVIM - running on the same
machine. I'm not talking about multiple tabs in a single instance.

Normally, when you have a setup like this, and you make changes in one
window, then switch over to the other one, it will notice that the file has
changed and ask you if you want to reload it. I rely on this
functionality.

However, I've noticed that in the above describe scenario, this doesn't
happen. I don't get alerted to the fact that the "viewer" copy may be
out-of-date, and I have to periodically re-load it manually (via :e) to
make sure the view is up-to-date. I would prefer if I didn't have to do
this manually; I would prefer if it would automatically notice that the
file has changed.

Now, I realize there could be a thousand reasons why this is happening -
some of them bugs, others features - but I am wondering whether this is a
"known feature" and/or if there is any fix/workaround.

--
The difference between communism and capitalism?
In capitalism, man exploits man. In communism, it's the other way around.

- Daniel Bell, The End of Ideology (1960) -

[Michael van Schaik]

Op donderdag 10 maart 2022 om 14:03:09 UTC+1 schreef Kenny McCormack:

Hi Kenny,

I don't often edit files and check them in another window, but in this scenario
I always use a vertical split in stead of two instances of VIM.

This works fine for both readable and non-readable files.

This might be a workaround for your problem.

Cheers.
Michael

[Kenny McCormack]

In article <e27d17b1-2ab5-41d4...@googlegroups.com>,
Michael van Schaik <mcjvan...@gmail.com> wrote:
...

>Hi Kenny,
>
>I don't often edit files and check them in another window, but in this

>scenario I always use a vertical split instead of two instances of VIM.

>
>This works fine for both readable and non-readable files.
>
>This might be a workaround for your problem.

For reasons that are beyond the scope of this thread, they must be separate
processes - given the system architecture.

That's the whole point.

Anyway, to further clarify, I think the problem is that VIM treats
read-only buffers "specially" and, in particular, assumes that since you're
not going to be writing anything from this buffer (at least, you're not
supposed to), it doesn't need to warn you that you are about to do
something bad (i.e., it doesn't need to track the modification date of the
file in order to prevent you from over-writing a new file with an old one -
again, since you're not going to be writing it at all).

I'm basically seeking confirmation that my analysis is correct - that this
is, in the terminology of old, a "known feature".

--
"The most unsettling aspect of my atheism for Christians is
when they realize that their Bible has no power to make me
wince. They are used to using it like a cattle prod to get
people to cower into compliance." - Author unknown

[Fred Weigel]

Not true. Just tried it with vim on Fedora 35.

view file -- in one terminal
vi file -- in another terminal
-- edit and save
As soon as the file is saved, get W11: Warning File "file" has changed since editing started. ...Ok, Load... in the view terminal.

So, it works as you want it too. This is with VIM 8.2

: fred@llana VPR $; vi --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 01 2022 00:00:00)
Included patches: 1-4485
Modified by <bugz...@redhat.com>
Compiled by <bugz...@redhat.com>
Huge version without GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm -tcl
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
-balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +gettext +num64 +textobjects
-browse -hangul_input +packages +textprop
++builtin_terms +iconv +path_extra +timers
+byte_offset +insert_expand +perl/dyn +title
+channel +ipv6 +persistent_undo -toolbar
+cindent +job +popupwin +user_commands
-clientserver +jumplist +postscript +vartabs
-clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +vim9script
+cmdline_hist +langmap -python +viminfo
+cmdline_info +libcall +python3/dyn +virtualedit
+comments +linebreak +quickfix +visual
+conceal +lispindent +reltime +visualextra
+cryptv +listcmds +rightleft +vreplace
+cscope +localmap +ruby/dyn +wildignore
+cursorbind +lua/dyn +scrollbind +wildmenu
+cursorshape +menu +signs +windows
+dialog_con +mksession +smartindent +writebackup
+diff +modify_fname +sodium -X11
+digraphs +mouse -sound -xfontset
-dnd -mouseshape +spell -xim
-ebcdic +mouse_dec +startuptime -xpm
+emacs_tags +mouse_gpm +statusline -xsmp
+eval -mouse_jsbterm -sun_workshop -xterm_clipboard
+ex_extra +mouse_netterm +syntax -xterm_save
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -tag_old_static
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DSYS_VIMRC_FILE=/etc/vimrc -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,--enable-new-dtags -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -L/usr/local/lib -o vim -lm -lselinux -lncurses -lsodium -lacl -lattr -lgpm -Wl,--enable-new-dtags -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fstack-protector-strong -L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm -lcrypt -lutil -lc
: fred@llana VPR $;

[Spiros Bousbouras]

On Fri, 11 Mar 2022 15:43:49 -0000 (UTC)
gaz...@shell.xmission.com (Kenny McCormack) wrote:
> Anyway, to further clarify, I think the problem is that VIM treats
> read-only buffers "specially" and, in particular, assumes that since you're
> not going to be writing anything from this buffer (at least, you're not
> supposed to), it doesn't need to warn you that you are about to do
> something bad (i.e., it doesn't need to track the modification date of the
> file in order to prevent you from over-writing a new file with an old one -
> again, since you're not going to be writing it at all).
>
> I'm basically seeking confirmation that my analysis is correct - that this
> is, in the terminology of old, a "known feature".

The behaviour was not known to me and your analysis doesn't make sense for
the reason you have already encountered and that is that you still want to be
notified of changes to the file (by a different process) in a readonly
buffer.

My guess is that the behaviour has something to do with how often vim checks
for changes. Doing :help timestamp does not mention what causes vim to
check the timestamp. For graphical vim I would guess that getting notified
by the window manager that the vim window has received input focus , causes
vim to check the timestamp of the file. So try to do something with your
window manager or vim window to make sure that vim receives an "input
focus" (or whatever the correct term is) event and see if vim notifies you
that the file has been changed by another process.

The :help timestamp page also mentions FileChangedShell and
checktime which may be useful.

--
vlaho.ninja/prog

[Eric Pozharski]

with <U8vGyqlX...@bongo-ra.co> Spiros Bousbouras wrote:
> On Fri, 11 Mar 2022 15:43:49 -0000 (UTC)
> gaz...@shell.xmission.com (Kenny McCormack) wrote:

>> I'm basically seeking confirmation that my analysis is correct - that
>> this is, in the terminology of old, a "known feature".

That's weird and suspicious. You don't have to post for confirmation,
sources of vim are readily available.

> The behaviour was not known to me and your analysis doesn't make sense
> for the reason you have already encountered and that is that you still
> want to be notified of changes to the file (by a different process) in
> a readonly buffer.
>
> My guess is that the behaviour has something to do with how often vim
> checks for changes.

Honestly, for all these years I have no slightest idea what logic is in
those checks. Then, after painful years, I"ve spotted a solution:

nmap <silent> <Leader><Leader>t :checktime<CR>

I've verified, works with read-only buffers too. Now, if you're of gvim
tribe then you can automate it even further with 'au FocusGained'.

*CUT*

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[Kenny McCormack]

In article <slrnt2p8c2...@orphan.zombinet>,

Eric Pozharski <why...@pozharski.name> wrote:
>with <U8vGyqlX...@bongo-ra.co> Spiros Bousbouras wrote:
>> On Fri, 11 Mar 2022 15:43:49 -0000 (UTC)
>> gaz...@shell.xmission.com (Kenny McCormack) wrote:
>
>>> I'm basically seeking confirmation that my analysis is correct - that
>>> this is, in the terminology of old, a "known feature".
>
>That's weird and suspicious. You don't have to post for confirmation,
>sources of vim are readily available.
>
>> The behaviour was not known to me and your analysis doesn't make sense
>> for the reason you have already encountered and that is that you still
>> want to be notified of changes to the file (by a different process) in
>> a readonly buffer.
>>
>> My guess is that the behaviour has something to do with how often vim
>> checks for changes.
>
>Honestly, for all these years I have no slightest idea what logic is in
>those checks. Then, after painful years, I"ve spotted a solution:
>
> nmap <silent> <Leader><Leader>t :checktime<CR>

Thank you. This looks promising.

>I've verified, works with read-only buffers too. Now, if you're of gvim
>tribe then you can automate it even further with 'au FocusGained'.

Indeed.

--
In the corner of the room on the ceiling is a large vampire bat who
is obviously deranged and holding his nose.

[Kenny McCormack]

In article <t0jcr1$1ibev$1...@news.xmission.com>,
Kenny McCormack <gaz...@shell.xmission.com> wrote:
...

>>Honestly, for all these years I have no slightest idea what logic is in
>>those checks. Then, after painful years, I"ve spotted a solution:
>>
>> nmap <silent> <Leader><Leader>t :checktime<CR>
>
>Thank you. This looks promising.
>
>>I've verified, works with read-only buffers too. Now, if you're of gvim
>>tribe then you can automate it even further with 'au FocusGained'.

Yes. I have now verified that using "checktime" periodically is the
solution for me.

I just re-ran the experiment and found that, indeed, after I'd made a
change to the file in another window (vim process), I did not get prompted
to re-load (in the viewer/read-only process) unless/until I did
"checktime". Immediately after doing "checktime", I was prompted (in a GUI
way) to re-load the file.

--
To be evangelical is to spend every waking moment hovering around
two emotional states: fear and rage. Evangelicals are seriously the
angriest and most vicious bunch of self-pitying, constantly-moaning
whinybutts I've ever encountered.