Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Sorry for the blank bug. It didn't seem to select a component, and when I hit enter to tell it I wanted vim it automatically created the bug even though it wasn't done. The problem is that vim no longer reads my .vimrc with the latest version of vim. Even when I use the -u option, it is ignored. version: Name : vim-common Epoch : 2 Version : 8.1.450 Release : 1.fc28 Architecture: x86_64 Install Date: Wed 03 Oct 2018 01:31:31 PM MST Every time, I've tried various things with no success. Actual: vim starts with system defaults. Expected: vim starts with my .vimrc Additional: Maybe there is something wrong in my .vimrc that this new version takes exception to, and just throws it away. I'll attach the .vimrc
Created attachment 1491435 [details] .vimrc file
The attachment window says all files, but there were no . files. That seems like a bad omission.
The two things that I've really noticed are: shiftwidth, it's set to two in the .vimrc, but unless I set it manually in the file it is 4. folding, I set a fold pattern in the file, but it is ignored.
OK, I think I found the issue. I downgraded to the last version (408), and put the .vim and .vimrc back to the original, and everything worked. I then tried the 8.1 configuration, and it had the issue. So, I substituted files until I found that it was ftplugin/python.vim that was causing the issue. I copied it to the .vim and edited to comment out " if !exists("g:python_recommended_style") || g:python_recommended_style != 0 " As suggested by PEP8. " setlocal expandtab shiftwidth=4 softtabstop=4 tabstop=8 " endif and everything works again. I updated to 450, and it also works now, with the commented out ftplugin for python. I built version 451 locally, and it also works with that change. I don't think that the plugin should override values from the .vimrc, but I leave it up to you whether this is actually a bug, and whether to close the bugzilla.
Hi stan, I'm sorry for not answering sooner, I got caught in other issues... I'm unable to reproduce the issue on my machine with your .vimrc. IMHO it is really bug. Would you mind helping me bisecting the commit which caused it? I will do a bisect of upstream code and issuing the builds, then send it to you for testing and you give me answer if it is okay or not. This way we can isolate the commit, which we will report to upstream.
To be precise, I couldn't reproduce it with your .vimrc, where I commented out 'colorscheme ordinarydark' line, because I don't have that plugin... maybe if you comment it out too, then your .vimrc will be loaded?
ordinarydark is a color scheme I created from another scheme that is dark. I tried other schemes and didn't like them. I'll try without it. I don't think that is the issue, because yesterday I was running it and everything was fine. It was also fine when I ran version 408. As long as I have the python.vim with the commented out Pep enforcement in my .vim/ftplugin, vim reads my .vimrc and runs the way I expect it to. The color scheme loads just fine. If I move that, the issue occurs. I'm currently using the 451 version that I compiled from rawhide source. What version would you like me to run? And how should I get it? I think this might be an older problem. I've been running with an old ~/.vim from years ago, and I think the 450 version finally introduced an incompatibility that caused the issue. So I moved that out of the way, and my ~/.vim contains only the custom color scheme, the ftplugin for python I modified , and the copy of .vimrc as vimrc. Everything else is sourced from the system defaults that were installed with 451. Thanks for your help.
(In reply to stan from comment #8) > As long as I have the python.vim with the commented out Pep enforcement in > my .vim/ftplugin, vim reads my .vimrc and runs the way I expect it to. The > color scheme loads just fine. If I move that, the issue occurs. It would be a change in internals of Vim, because that part of python.vim is there quite long time and haven't caused the issue yet. > I'm currently using the 451 version that I compiled from rawhide source. What > version would you like me to run? And how should I get it? > First, to be clear - 408 version works fine and 450 doesn't work? If that's so, any version between them is fine, but because there isn't such version in fedora git, then we need to take source code (probably when we will be bisecting the upstream project between 408 and 450 patchlevels) from upstream and compiling it in fedora git to create rpms, which you will test. I can do creating rpms for you, if you want. (In reply to stan from comment #8) > As long as I have the python.vim with the commented out Pep enforcement in > my .vim/ftplugin, vim reads my .vimrc and runs the way I expect it to. Why do you have python.vim in ~/.vim ? It should be loaded from /usr/share/vim/vim81/ftplugin... isn't a part of a plugin of some sort? I reported it upstream as https://github.com/vim/vim/issues/3555
Would you mind attaching the output of commands in Vim: :scriptnames :set rtp? Or it would fasten the process if you join the discussion at upstream issue.
"First, to be clear - 408 version works fine and 450 doesn't work?" I just downgraded, checked again, and without the change in ftplugin/python.vim described above, my settings for sw in .vimrc are ignored. So, the answer is that 408 doesn't work either. It worked with the old .vim I had that was several years old, a copy of an earlier versions /usr/share/vim/*. Here is the output of :scriptnames running vim in konsole in X. 1: /etc/vimrc 2: /usr/share/vim/vim81/syntax/syntax.vim 3: /usr/share/vim/vim81/syntax/synload.vim 4: /usr/share/vim/vim81/syntax/syncolor.vim 5: /usr/share/vim/vim81/filetype.vim 6: /usr/share/vim/vimfiles/ftdetect/augeas.vim 7: /usr/share/vim/vimfiles/ftdetect/clustershell.vim 8: /usr/share/vim/vimfiles/ftdetect/nginx.vim 9: /usr/share/vim/vimfiles/ftdetect/ninja.vim 10: /usr/share/vim/vimfiles/ftdetect/proto.vim 11: /usr/share/vim/vimfiles/ftdetect/puppet.vim 12: /usr/share/vim/vimfiles/ftdetect/stp.vim 13: /usr/share/vim/vimfiles/ftdetect/votl.vim 14: /usr/share/vim/vim81/ftdetect/lilypond.vim 15: /usr/share/vim/vim81/ftplugin.vim 16: ~/.vimrc 17: /usr/share/vim/vim81/syntax/nosyntax.vim 18: /usr/share/vim/vim81/indent.vim 19: ~/.vim/colors/ordinarydark.vim 20: /usr/share/vim/vimfiles/plugin/SyntaxFolds.vim 21: /usr/share/vim/vimfiles/plugin/cctree.vim 22: /usr/share/vim/vimfiles/plugin/command-t.vim 23: /usr/share/vim/vimfiles/autoload/commandt/mirkwood.vim 24: /usr/share/vim/vimfiles/plugin/filebrowser.vim 25: /usr/share/vim/vimfiles/plugin/imaps.vim 26: /usr/share/vim/vimfiles/plugin/javabrowser.vim 27: /usr/share/vim/vimfiles/plugin/parrot.vim 28: /usr/share/vim/vimfiles/plugin/perl-support.vim 29: /usr/share/vim/vimfiles/autoload/mmtoolbox/tools.vim 30: /usr/share/vim/vimfiles/autoload/mmtoolbox/make.vim 31: /usr/share/vim/vimfiles/plugin/remoteOpen.vim 32: /usr/share/vim/vimfiles/plugin/rnv.vim 33: /usr/share/vim/vimfiles/plugin/syntastic/autoloclist.vim 34: /usr/share/vim/vimfiles/plugin/syntastic/balloons.vim 35: /usr/share/vim/vimfiles/plugin/syntastic/checker.vim 36: /usr/share/vim/vimfiles/plugin/syntastic/cursor.vim 37: /usr/share/vim/vimfiles/plugin/syntastic/highlighting.vim 38: /usr/share/vim/vimfiles/plugin/syntastic/loclist.vim 39: /usr/share/vim/vimfiles/plugin/syntastic/modemap.vim 40: /usr/share/vim/vimfiles/plugin/syntastic/notifiers.vim 41: /usr/share/vim/vimfiles/plugin/syntastic/registry.vim 42: /usr/share/vim/vimfiles/plugin/syntastic/signs.vim 43: /usr/share/vim/vimfiles/plugin/syntastic.vim 44: /usr/share/vim/vimfiles/autoload/syntastic/util.vim 45: /usr/share/vim/vimfiles/plugin/taglist.vim 46: /usr/share/vim/vim81/plugin/getscriptPlugin.vim 47: /usr/share/vim/vim81/plugin/gzip.vim 48: /usr/share/vim/vim81/plugin/logiPat.vim 49: /usr/share/vim/vim81/plugin/manpager.vim 50: /usr/share/vim/vim81/plugin/matchparen.vim 51: /usr/share/vim/vim81/plugin/netrwPlugin.vim 52: /usr/share/vim/vim81/plugin/rrhelper.vim 53: /usr/share/vim/vim81/plugin/spellfile.vim 54: /usr/share/vim/vim81/plugin/tarPlugin.vim 55: /usr/share/vim/vim81/plugin/tohtml.vim 56: /usr/share/vim/vim81/plugin/vimballPlugin.vim 57: /usr/share/vim/vim81/plugin/zipPlugin.vim 58: /usr/share/vim/vim81/ftplugin/python.vim 59: /usr/share/vim/vim81/syntax/python.vim 60: /usr/share/vim/vim81/indent/python.vim 61: /usr/share/vim/vimfiles/autoload/syntastic/log.vim This is the output of running :set rtp? in konsole in X. runtimepath=~/.vim,/usr/share/vim/vimfiles,/usr/share/vim/vim81,/usr/share/vim/vimfiles/after,~/.vim/after "Why do you have python.vim in ~/.vim ? It should be loaded from /usr/share/vim/vim81/ftplugin... isn't a part of a plugin of some sort?" It is in ~/.vim/ftplugin/. I wasn't clear, making the assumption that you would assume the same structure as under /usr/share/vim. But for these tests I moved it to a backup, so it was not in ~/.vim/ftplugin, and system version was used. I went to the above ticket for vim at github, and it seems that this behavior is not considered a bug. "So it is only about the python filetype plugin setting some options as suggested by PEP8? That is not a bug and has been discussed several times. You can always use FileType plugins (for example in the after directory) to overwrite filetype specific settings." and "But all hope isn't lost. If you can find what setting that you don't like is set by which ftplugin, you can override it either in an after/ftplugin for the same filetype (e.g. in a new script named ~/.vim/after/ftplugin/python.vim), or in an autocommand for the VimEnter event (which is triggered at the very end of startup)." I was going to suggest that I install the git repository and do the bisection locally. But the above two quotes suggest that I have wasted your time, because the behavior I am seeing is vim behaving as expected. And they even give me the workaround. Those guys are on top of things, I was impressed with their responses. Sorry for the noise, and thanks again for your trouble.
(In reply to stan from comment #11) > I was going to suggest that I install the git repository and do the > bisection locally. But the above two quotes suggest that I have wasted your > time, because the behavior I am seeing is vim behaving as expected. And > they even give me the workaround. Those guys are on top of things, I was > impressed with their responses. Sorry for the noise, and thanks again for > your trouble. What confused me was the change of behavior between two versions and I understood it as it has impact on all files, because .vimrc seemed to not be applied. But the first you found out it isn't true and for other two ':scriptnames' gave a exact answer... Either way, no problem, at least I learnt something new.