I am experiencing something very similar. In my case it's 'lines' that is
"mysteriously" changed during gVim startup.
Normally, after gVim is started, vim (:set lines? columns?) reports 24
lines and 80 columns. But sometimes starting gVim ends up with a smaller
window having only 22 lines and 80 columns. In those cases the change of
the window height is visible during startup: At first a 24x80 gVim window
appears and even the usual intro screen is displayed for a fraction of a
second. But then suddenly the window height gets cut down, the intro screen
disappears (supposedly due to a redraw triggered by the window size change)
and I then end up with a smaller gVim window (22x80). The clustering of the
"bad" cases is similar too. When starting gVim sequentially 5 times in a
row it's not uncommon that I get 1 good case and then 4 bad ones. What is
also different from OP is that I have a classic spinning HDD. Not an SSD.
And I do not notice any correlation between bad gVim startups and system
activity.
I am on Debian 10.12 with Cinnamon Desktop Environment 3.8.8. My gVim is
provided by vim-gtk 2:8.1.0875-5+deb10u2 Debian package. So it's basically
Vim version 8.1.0875 with some later patches applied on top of it.
To rule out my .vimrc and plugins I just tried to start gVim a few times
with "vim -g --clean" and I mostly got the same. The only notable
difference was that the bad cases had 20x80 window (i.e. 2 more lines were
cut compared to the bad cases without --clean).
I wonder if this can be caused by Cinnamon DE somehow. But I haven't had
opportunity to test on a similar setup with different DE. What is your
desktop environment, errael?
Tom
On Saturday, April 9, 2022 at 2:46:24 AM UTC+2 errael wrote:
> Steps to reproduce
>
> The plugin I'm working with has had a long standing intermittent issue.
> &columns set on the command line did not always work. I've tried various
> suggestions, seemed to fix it, then it would show up again. The last time
> it was happening, I instrumented it. When the user command, Init, is
> executed the value of &columns is what I set on the command line. But
> occasionally some time later &columns has the default value.
>
> *NOTE:* This is not an issue any more (or at least it doesn't seem to
> be). The plugin detects that &columns has changed, and sets it back to what
> it should be and the screen is drawn with the correct width. But I wanted
> to document it.
>
> There's a vim script below that fails only a few percent of the time if
> anyone's curious. The failures are often clustered when I run it. The
> failures seem to happen if there's other system activity. I'm running on a
> big memory and SSD system; I'm beginning to think that might have something
> to do with the low failure rate.
>
> Starting vim like:
>
> gvim -f -c "set co=120" -c "Init"
>
> Here's an excerpt to see the idea: the value of &columns occasionally
> changes between Boot() and Trampoline()
>
> vim9script
>
> command! -nargs=0 Init call Boot()
>
> var startup_columns: number
>
> def Trampoline(id: number)
> if startup_columns != &co
> Log(printf('FAIL: expected %d, got %d', startup_columns, &co))
> endif
> enddef
>
> export def Boot()
> startup_columns = &columns
> timer_start(50, Trampoline)
> enddef
>
> If you run the script below, it creates /tmp/test_home with a
> .vim/pack/... and also a script. Do bash /tmp/test_home/run.sh
> [num-interations] to run the script. Note that when gvim is run, it uses
> the new directory as $HOME. It output its progress to the console and
> leave a log file. Notice that plugin has a DoStuff() function that does
> file IO, and which can be tweaked to adjust the amount of work.
>
> Console output looks like:
>
> ...
> Iteration 4: total bytes read 9876
> Iteration 5: total bytes read 8649
> FAIL: expected 120, got 100
> Iteration 6: total bytes read 4639
> Iteration 7: total bytes read 15394
> FAIL: expected 120, got 100
> Iteration 8: total bytes read 1275
> ...
>
> Source this to create the test
>
> vim9script
> var test_home = '/tmp/test_home'
> test_home->delete('rf')
> var plug_dir = test_home ..
> '/.vim/pack/random-packages/start/columns_issue/plugin'
> var lines =<< trim END
> vim9script
>
> command! -nargs=0 Init call Boot()
>
> def Log(msg: string)
> writefile([ msg ], '/dev/tty', 'a')
> enddef
>
> var iteration: any
> var startup_columns: number
>
> def Trampoline(id: number)
> if startup_columns != &co
> Log(printf('FAIL: expected %d, got %d', startup_columns, &co))
> cq
> endif
> qa
> enddef
>
> var Busy: func
> export def Boot()
> startup_columns = &columns
> iteration = g:->get('xxx', 'none')
> Busy()
> timer_start(50, Trampoline)
> enddef
>
> def DoStuff()
> var basedir: string
> var total = 0
> def F(n: string)
> try
> var f = readfile(basedir .. '/' .. n, 'Bb')
> total += len(f)
> catch /.*/
> Log(printf('Read of %s failed: %s', n, v:exception))
> endtry
> enddef
> basedir = '/bin'
> var dir = readdir(basedir)
> for i in range(15)
> F(dir[ rand() % len(dir) ])
> endfor
> Log(printf('Iteration %s: total bytes read %d', iteration, total))
> enddef
> Busy = DoStuff
> END
> plug_dir->mkdir('p')
> lines->writefile(plug_dir .. '/script.vim')
>
> lines =<< trim END
> #!/bin/bash
>
> i=0
> bound=${1:-100}
> while ((++i <= bound)); do
> if HOME=TEST_HOME gvim -f -c "vim9 g:['xxx'] = $i" -c "set co=120" -c
> "Init"
> then
> echo OK $i >> TEST_HOME/log
> else
> echo FAIL $i >> TEST_HOME/log
> fi
> done
> echo $(dc <<< "4k $(grep FAIL TEST_HOME/log | wc -l) \
> $(wc -l < TEST_HOME/log) / 100 * p") "% failures"
> END
> lines->map((_, v) => substitute(v, 'TEST_HOME', test_home, ''))
> lines->writefile(test_home .. '/run.sh')
>
> Expected behaviour
>
> Never fails.
>
> As mentioned, I think this is no longer an issue for the plugin. It
> detects the problem and sets the column back to what it's supposed to be.
> Things work OK from that point on.
> Version of Vim
>
> 8.2.4701
> Environment
>
> ubuntu (pop_os), gvim-gtk3
> Logs and stack traces
>
> *No response*
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/vim/vim/issues/10123>.
> You are receiving this because you are subscribed to this thread.Message
> ID: <vim/vim/issues/[email protected]>
>
--
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/39dd9f71-4829-4e71-bff8-7f115dce1dc3n%40googlegroups.com.
