Support for org-refile-use-outline-path

[chipsenkbeil]

Does this feature exist in Emacs orgmode core?

Yes

Orgmode link

• Manual mention: https://orgmode.org/org.html#index-org_002drefile_002duse_002doutline_002dpath
• Additional explanation: https://emacs.stackexchange.com/questions/36505/org-mode-refile-multiple-locations-with-same-name-as-target

~~While the manual mentions the variable, I can't actually find manual documentation on its values. There are multiple website discussions such as stackexchange that provide examples of the options, though.~~

Feature value

No response

Additional context

Suppose I want to have an org file named work.org that looks like this:

* Project 1
** Tasks
* Project 2
** Tasks 

I can only refile today using a destination like work.org/Tasks, which will place under the first heading that matches. I'd like to have a singular file where I can file tasks into different headings without either

a. Making them top-level and distinct such as Project 1 Tasks and Project 2 Tasks b. Breaking out into separate files such as project_1.org/Tasks and project_2.org/Tasks when refiling

[chipsenkbeil]

Seems related to https://github.com/nvim-orgmode/orgmode/discussions/513.

[seflue]

Interesting issue, which exposes a feature gap between nvim-orgmode and Emacs Orgmode. I would be curious to implement it, but I would prefer to first refactor the refiling code a bit more seriously, because this feature touches a couple of points, which currently treat headline names like a unique identifier within one org file.

This includes also some user interface decisions, which we need to discuss.

[chipsenkbeil]

@seflue what can I do to help here? Is there a tracker for the refile refactoring?

I've got experience writing neovim plugins such as https://github.com/chipsenkbeil/distant.nvim, so maybe I can pitch in a bit.

[seflue]

There is currently no tracker regarding this refactoring, but because I spend some time in the refiling code the last days while fixing some issue, I came to the conclusion, that it would make future changes easier to refactor it a little bit. Currently the code is sometimes a little bit ambiguous to read, also a bit entangled, which makes it challenging to understand. But because I already invested some time to grasp it, it would make sense to use this knowledge, to improve it.

I deferred such a refactoring, because the fixes I did recently were only small changes. The feature you suggest is a bit larger, so doing the refactoring before that would make things easier. @kristijanhusak is the decision maker here, I don't know, how he sees the priorities. But generally speaking: if you are currently very motivated to contribute on this particular topic, feel free to create a PR. I currently cannot promise, when I would find time for the mentioned refactoring and I also have other bugs and feature gaps, which are higher on my priority list, because they have a higher impact on my day-to-day work.