search

wbthomason / packer.nvim

A use-package inspired plugin manager for Neovim. Uses native packages, supports Luarocks dependencies, written in Lua, allows for expressive config
MIT License
7.83k stars 266 forks source link

Lazy loading can change filetype #604

Open xenrox opened 3 years ago

xenrox commented 3 years ago

Steps to reproduce

see https://github.com/TimUntersberger/neogit/issues/216

Actual behaviour

Filetype gets changed.

Expected behaviour

Filetype remains the same

packer files

Plugin specification file(s) See minimal config in original issue
packer log file Post the contents of ~/.cache/nvim/packer.nvim.log here
packer compiled file Post the contents of `packer_compiled.vim` here

Edit: I am not the original poster, but help my friend debug this problem.

akinsho commented 3 years ago

@wbthomason @xenrox so I actually first reported this issue over in neogit in https://github.com/TimUntersberger/neogit/issues/181#issuecomment-919013652. I had initially assumed neogit was doing something and tbh before that I had assumed it might have been null-ls but we narrowed down the changing to lazy load triggers for plugins. I wonder if it might have something to do with the filetype loading issues that resulted in a change to that logic I remember a PR a couple of weeks ago that changed the loading, and I am wondering if it could have led to this.

I'll try pinning packer to an old commit (before the filetype changes) for a day and see if the bug reproduces, since it's quite sporadic, unless someone has clear predictable steps for reproduction.

xenrox commented 3 years ago

@akinsho The minimal config of gowep works as e regular reproducer for me.

I wanted to usegit bisect to find a faulty commit but even going as far back as 2ac8823 still causes the bug, so it seems like it never worked correctly.

akinsho commented 3 years ago

@xenrox I've been using neogit and packer for quite a while now and this has not been a consistent problem I've only noticed it for the last 1-2 months etc.

wbthomason commented 3 years ago

If https://github.com/wbthomason/packer.nvim/commit/add255996af31fcec142cb28faa99998c2d5ac4e isn't what broke this, then perhaps https://github.com/wbthomason/packer.nvim/blob/0d6701ed8cf4a590ccb26bbbb7b884c6ce18b0c0/lua/packer/load.lua#L77-L79 has always been a problem?

wbthomason commented 3 years ago

I would suspect add2559, though.

xenrox commented 3 years ago

I would suspect add2559, though.

Commenting out that line does not change anything.

wbthomason commented 3 years ago

@xenrox What about line 111 (the filetypeplugin autocommand line), if you don't mind?

xenrox commented 3 years ago

@xenrox What about line 111 (the filetypeplugin autocommand line), if you don't mind?

That changed nothing as well. But it seems like this code does not even get called. I added log.error 'DEBUG' after elseif cause.ft then and while I reproduced the bug a few times, only one "DEBUG" appeared in the log file.

xenrox commented 3 years ago

The trigger for lazy loading the two plugins (telescope and neogit) is command based not filetype based.

akinsho commented 3 years ago

Hmm, despite this, I rolled my version of packer to the commit before add2559 and didn't hit the issue at all today 🤔. I'll try to put some logs in and see if there's some edge case that makes it fall into that clause or if the issue is actually coming from one of the commits between that and HEAD

akinsho commented 2 years ago

@wbthomason I actually managed to consistently reproduce this issue by going into neogit's commit buffer and running doautocmd BufRead this causes the buffer to be re-evaluated and the filetype to be changed. I'm not sure what the command is for and when exactly it triggers, so not sure how to fix it. Should it be blocked for gitcommit type buffers or is it firing in the wrong place and shouldn't be going off at all maybe?

EDIT: just read through the code and realised it's for plugins that have ftplugin dirs and ensuring their filetypes are reloaded, I'm wondering if it is done too bluntly atm or why it triggers inside neogit's commit buffers at all