Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix!: tangle files relative to norg file #1415

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

benlubas
Copy link
Contributor

@benlubas benlubas commented May 4, 2024

Tangled file paths were relative to the current working directory, so tangle behavior was unpredictable. Additionally, the current parser bug that prevents tangling to nested folders made it practically impossible to tangle to a nested folder (unless you wanted to change your working directory or open nvim from the very nested folder, both of which are impractical).

Labeled as a breaking change

@vhyrro
Copy link
Member

vhyrro commented May 17, 2024

Unsure if we should mark this a breaking change. I would treat this as a regular bug fix - it's unlikely that the user's CWD would diverge from the cwd of the file they're editing, and so a small subset of users are affected.

If we really want to keep this as a breakage, I would keep this PR open until we're about to hit 9.0.0, after the nvim-treesitter dependency is dropped and after luarocks.nvim is stabilized further :)

@benlubas
Copy link
Contributor Author

Leaning towards merging sooner than later. tangle is more or less unusable for me without it. It's just something that could really mess with anyone using tangle.

I wind up editing notes from different working directories all the time especially if a want to write a literate config and tangle it, I often jump to my config from wherever I was when I wanted to change my config.

Comment on lines +328 to +332
local path_lib_path = Path.new(file_to_tangle_to)
if path_lib_path:is_relative() then
local buf_path = Path.new(buf_name)
file_to_tangle_to = tostring(buf_path:parent():child(file_to_tangle_to):resolve())
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tbf couldn't this be broken down into just vim.fn.expand("%:h")? That'll return the head of the path to the current buffer. Wrap that in a vim.api.nvim_buf_call and you'll get a faster and cleaner implementation :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not following. getting the head of the file is just a part of what pathlib is doing here.

Could you give an example or suggest a change?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I meant that this can be much more succinctly written by using vim.fn instead of the extra work that's being done here. An example would just be:

file_to_tangle_to = vim.fs.joinpath(vim.fn.expand("%:h"), file_to_tangle_to)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't work if file_to_tangle_to is an absolute path. We would still need the is_relative check.

@max397574
Copy link
Contributor

I'm able to tangle with a config like this:

tangle: {
    languages: {
        lua: ../lua/neocomplete/types/config.lua
    }
    scope: tagged
    delimiter: none
}

so I'm not really sure what's the issue here
this is relative to the norg file and it tangles to nested folder (which according to this pr shouldn't work)

@max397574
Copy link
Contributor

will pathlib also allow to remove this horrible hack? https://github.com/nvim-neorg/neorg/pull/1167/files

@benlubas
Copy link
Contributor Author

benlubas commented Jul 8, 2024

this is relative to the norg file

I mean that's just wrong. If you tangle to just ./out.lua and change directories it's much easier to see that tangling always puts the file in your cwd.


The parser bug referenced was for tagging individual code blocks to be tangled. You are correct that you can specify a longer path in metadata.

@benlubas
Copy link
Contributor Author

benlubas commented Jul 8, 2024

will pathlib also allow to remove this horrible hack? #1167 (files)

yeah it should solve this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants