`create_in_closed_folder` doesn't apply to paste

[ehaynes99]

Description

When the create_in_closed_folder option is set, creating a file with a directory highlighted creates the file in the directory that's highlighted. When pasting a file, it does not.

Not to sound disrespectful, but I'm a little unclear as to why this option is needed at all... Is this just precedent from NerdTree? It's unusual behavior for graphical file trees anywhere else for the opened state of a selected directory to impact paste. I can't imagine I'm the first to notice, but there were no other issues...

Neovim version

NVIM v0.8.1
Build type: Release
LuaJIT 2.1.0-beta3

Operating system and version

Operating System: Arch Linux Linux 5.15.78-1-lts

nvim-tree version

829e9f6

Minimal config

vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvt-min/site]]
local package_root = "/tmp/nvt-min/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
  require("packer").startup {
    {
      "wbthomason/packer.nvim",
      "nvim-tree/nvim-tree.lua",
      "nvim-tree/nvim-web-devicons",
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. "/plugin/packer_compiled.lua",
      display = { non_interactive = true },
    },
  }
end
if vim.fn.isdirectory(install_path) == 0 then
  print "Installing nvim-tree and dependencies."
  vim.fn.system { "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path }
end
load_plugins()
require("packer").sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua setup()]]
vim.opt.termguicolors = true
vim.opt.cursorline = true

-- MODIFY NVIM-TREE SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
_G.setup = function()
  require("nvim-tree").setup {}
end

Steps to reproduce

Create a directory like:

.
├── bar
│   └── baz
└── foo.xyz

1. select bar
2. press <CR>
3. select foo.xyz
4. press x
5. select bar/baz
6. press p

Expected behavior

File becomes /bar/baz/foo.xyz

Actual behavior

File becomes /bar/foo.xyz

[alex-courtis]

#622 added this. It's definitely a niche use case that only applies to creation, nothing else.

Is this causing a problem? What's the use case you are seeking?

Are there any additional actions you'd expect this option to affect?

[ehaynes99]

So I guess there are 2 things going on. Looking at #622, I think the default was unintentionally flipped in #1279. The option is off by default now, so the niche case is now the standard behavior for create:

nvim-tree.lua/lua/nvim-tree.lua

Line 450 in 829e9f6

create_in_closed_folder = false,

That's the reverse of the documented behavior where you would have to explicitly set it to 0 to get the unusual behavior.

nvim-tree.lua/lua/nvim-tree/legacy.lua

Lines 272 to 276 in 99d7136

	nvim_tree_create_in_closed_folder = function(o)
	if o.create_in_closed_folder == nil then
	o.create_in_closed_folder = vim.g.nvim_tree_create_in_closed_folder == 1
	end
	end,

But then additionally, the paste action has this behavior hardcoded:

nvim-tree.lua/lua/nvim-tree/actions/fs/copy-paste.lua

Lines 166 to 168 in f8489c9

	elseif not node.open then
	destination = vim.fn.fnamemodify(destination, ":p:h:h")
	end

"Problem" is a strong word, but I am frequently ending up with files in the parent of where I intended to put them. Intuitively, I would think that the below two screenshots -- whether for create or paste -- would add the file to /bar/baz. However, for both create and paste, it goes in /bar for the first case and /bar/baz for the second.

[ehaynes99]

My first statement there was wrong. Let's summarize:

• Prior to #622 , creating a file with a directory highlighted would place the file inside of the directory, always.
• #622 was a feature request asking to add an option so that created files would be created in the parent if the directory was closed
• The option added in PR #628 was numeric. According to the documentation added:

|g:nvim_tree_create_in_closed_folder| g:nvim_tree_create_in_closed_folder

Can be 0 or 1. 1 by default.

• However, there was nothing in the code that defaulted it to 1. This was a regression. The new "option" was actually the new default.
• Later #1015 changed the documentation to reflect the lack of a default to 1. I believe this to be incorrect. The bug was not the documentation, but the code. There was never actually anything setting the default to 0 either... it just worked because the check was an explicit comparison with 1
• When removing the globals in #1279, the new style was set to false to reflect the implicit 0.

  nvim-tree.lua/README.md

  Line 72 in 42597be

  create_in_closed_folder = false,

---

For paste, I don't really understand why it's hardcoded that way, but that dates back to the original addition of copy/paste (now divided) fs.lua

nvim-tree.lua/lua/lib/fs.lua

Line 158 in 9b20fcb

elseif not node.open then

[alex-courtis]

Thanks for all the digging!

I've been caught out by this myself and been most frustrated at this strange functionality. To be honest, I have not seen this option until you have pointed it out.

#1802

1. Apply the option to paste. That should definitely be done.
2. Change the default. That is a change in behaviour however I'm quite happy to change it now in the name of a very long running regression.

[alex-courtis]

I'm actually tempted to remove create_in_closed_folder completely. It's unintuitive and adds unnecessary complexity.

It could be removed via legacy.removed warning the user only if they are not using the default, however that's not really friendly as such users will have set the option to achieve sane behaviour which is the new default. Just removing silently is my preference.

@gegoune what are your thoughts on this removal and the above change in default?

[ehaynes99]

I think the issue with it is just that it's one of those "backwards booleans". Ideally, I always try to make the "normal" path of a feature toggle be the falsy version. I.e. "if it ain't in the config, it's off". Defaulting to true works, but it's easy to lose things like that in refactors. E.g. create_in_parent_when_closed or something.

#622 didn't really say why it was needed... I can't think of any other file tree that has that behavior. Since it was the default, I assumed that I just wasn't aware of some ancient precedent. However, you could also think of this as "unchanging the default". :-)

I'm kinda surprised that it wasn't filed before now. Until I dug around in the help for that option, I couldn't really tell what it was doing, just that things kept winding up in the wrong place.

[gegoune]

I am happy to remove that option if it's adding complexity. Well defined, sane behaviour is more important than an option.

(as a side not: I am pretty sure there will be more stuff like that, unneeded options that were added at a quick whim without good enough reason - we could review.)

@ehaynes99 Thanks for excellent and detailed investigation.

[alex-courtis]

I am happy to remove that option if it's adding complexity. Well defined, sane behaviour is more important than an option.

(as a side not: I am pretty sure there will be more stuff like that, unneeded options that were added at a quick whim without good enough reason - we could review.)

Yes please.

We could try removing this one as an experiment, notifying users that are not using the default.

Edit: I took a look at the dolphin file manager: create folder/file and paste on a folder puts it in that folder.

[alex-courtis]

Plan: #1802 (comment)