Unexpected 'nolink' behavior with neovim and packer [help]

[lyndhurst]

Hi,

I am just starting using dotdrop, and trying to get familiar with it before getting fancy with my configuration. So far everything has been working as I could expect from the documentation (backups, updates, installs and imports).

I have a simple configuration and I only imported my nvim configuration files. This means the .config/nvim/init.lua file, and my .config/nvim/lua/config/ directory where I keep each plugin configuration in a separate file (even the require("packer").startup function in a packer.lua file).

config:
  backup: true
  banner: true
  create: true
  dotpath: dotfiles
  keepdot: false
  link_dotfile_default: nolink
  link_on_import: nolink
  longkey: false
dotfiles:
  f_init.lua:
    src: config/nvim/init.lua
    dst: ~/.config/nvim/init.lua
  d_config:
    src: config/nvim/lua/config
    dst: ~/.config/nvim/lua/config
profiles:
  laptop:
    dotfiles:
    - f_init.lua
    - d_config

Since I am just starting to learn, I wanted to try out with nolink at first. I expected to have additional steps when tweaking my nvim config for changes to take effect like dotdrop install first and then some nvim reloading. But to my surprise that was not the case!

Changes made in the dotfiles repository take effect in nvim without doing a dotdrop install. Below are the steps to reproduce on my machine.

I edit my packer config file in the dotfiles repo using nvim, and I add a line like use "akinsho/toggleterm.nvim" I immediately do PackerCompile, then PackerSync, and the plugin gets installed.

I do a dotdrop compare and the diff confirms that the changes were not applied to the home folder. I do a bat ~/.config/..../packer.lua and the line added in the dotfiles src is not present there. I finally try dotdrop install, and the changes are mirrored to the home folder.

I tried the same kind of operations half a dozen times with consistent results, I am sorry for wasting your time if I missed something, but even after reading the doc, I feel that what I am describing is just not possible. I would greatly appreciate any help to understand what is happening.

Thank you for your time :)

[deadc0de6]

Hello,

Thanks for asking, you are absolutely not wasting my time, I'm happy to help!

You are right, since you use nolink, changes made to the dotfile in the dotpath (src) is not mirrored on the filesystem (dst) until you run dotdrop install. This is confirmed when you cat the file (with bat) as well as when using dotdrop compare.

I'm not using packer so I can't really say but wouldn't the :PackerCompile/:PackerSync read the current file somehow? But it is difficult to say without knowing what you mean by

Changes made in the dotfiles repository take effect in nvim

[deadc0de6]

Isn't that plugin maybe already enabled somewhere else in your ~/.config/..., a place from where nvim is already loading plugins? You can maybe to do a grep -r/ag there to try to look for toggleterm?

[lyndhurst]

Hi, thank you for answering so quickly, it was night time for me.

I am embarrassed to say that since this morning I cannot reproduce the issue. I was careful to triple check where the changes were being made and all, but I guess I was tired and must have made a mistake somewhere in the process.

Anyway, since everything is working as expected, and, now that you confirmed there are no magical hidden feature in dotdrop nor any conspiracy between you and the nvim devs to drive users crazy :) I can rest at ease and close this issue.

Thank you again for your quick advice, and this very cool piece of software.

[deadc0de6]

no worries, happy you solved it ;-)

[lyndhurst]

I had not solved it yet, I just could not reproduce the issue today. But, it happened again, and now I solved it. Of course it is a problem with my config, as it is 99% of the time.

It can be useful to other packer users that get puzzled like I did, so I will explain the problem here for future reference.

As advised in the packer documentation, I have an autocmd set to trigger the PackerCompile command when the packer config file is modified. Since both files in dest and src have the same name, the command gets triggered when modifying the file in src.

On top of that the auto command proposed in the documentation uses source <afile> before compiling, and <afile> stands for "current buffer", this is the reason why changes made to the nvim config in src affect the nvim instance used for editing the files.

You can find the autocmd I am refering to following that link and scrolling up a little. I will also paste the culprit here for everyone to see:

vim.cmd([[
  augroup packer_user_config
    autocmd!
    autocmd BufWritePost plugins.lua source <afile> | PackerCompile
  augroup end
]])

I am glad to have finally understood that mistery, that was kind of spooky! Vim users, beware of autocommands based on file name patterns when using dotdrop, that can have some unexpected effects ;)

[deadc0de6]

Note that you could use a completely different name for the src to avoid such issue (if you don't want to change your autocmd. Just rename the file in the dotpath and in the config (under src).

[lyndhurst]

That is a very good tip, I did not even think about it, but yes, it is just a key in a config file after all... Thanks.