feat: add base dirs (#73)

[tg0h]

Add base dirs to fix #73

Current Problem:

• The harpoon menu does not show, in a single menu, all the marks that I make in a mono repo
  • Instead the marks from child project a are shown in the harpoon menu that I open when in child project a
  • The marks from child project b are shown separately in another harpoon menu when opened from child project b
• This is caused by lsp changing the cwd when I open a file from a child project

Solution:

• Add a base_dirs key to global settings which can store an array of base_dirs
• Harpoon will get cwd and then refer to base_dirs when trying to determine the current project key
• If cwd is a child of base_dir, use the base_dir key instead

Note:

• To remove a base_dir that has been set up previously, specify base_dirs = {}. Do not remove the base_dirs global settings key entirely when calling harpoon.setup
• @ThePrimeagen I don't know if this works with git worktrees ... I never could get your git worktrees plugin to work ... someone test ? :D

Improvements:

• Does anyone know how to determine if a directory is a child of a filepath? I implement this hackily using Plenary's Path:new(cwd):make_relative(baseDir)

Limitations

• This does not work with the mark_branch=true global setting. (Because trying to figure out if /path/to/a/dir-feature-branch-1 is a child of /path/to/a/dir is painful. If anyone wants to take a stab at this .... :D
• I hope i did not break the tmux commands ... I notice they use cwd ... ¯_(ツ)_/¯

Questions

• How do send commands work in a mono repo? should the cwd of a command be the basedir ?

[tg0h]

• if I add an or condition to include "menu"
• and assuming that menu = {} (and not simply removed entirely) in the harpoon setup call
  then Selectively cache config #47 can also be fixed ... fyi @jesseleite

[jesseleite]

Heyo! So if I delete my custom menu = { ... } config (to revert to harpoon defaults in my setup method), would I still have to go and bust the cache myself somewhere? Hoping not 🙏

[tg0h]

yups,

• originally, if you did this to set up your menu

require("harpoon").setup({
    menu = {
        width = vim.api.nvim_win_get_width(0) - 4,
    }
-- other settings ... 
})

• later to remove your menu settings, you can do this

-- need to call setup again and pass an empty table to the menu key to clear the menu settings
require("harpoon").setup({
    menu = {}
-- other settings ... 
})

• unfortunately this won't work (removing the menu key entirely)

-- need to call setup again and pass an empty table to the menu key to clear the menu settings
require("harpoon").setup({
-- other settings ... 
})

no need to mess about with deleting the harpoon cache

---

From my preliminary testing, providing menu={} clears up the menu settings without needing to mess about with the cache.

This is caused by the current deep merge implementation which doesn't merge nicely. The nicer solution would be to clean up the deep merge function. The work around is to detect if we are attempting to merge the menu key and simply overwrite the 'left' table. Haven't created a PR for this yet though ... but should be simple enough to add an or condition and PR ...

[jesseleite]

Right, though I disagree with having to leave menu = {} to clear some cache. What I'm suggesting in #47 is to altogether avoid caching configs that don't benefit from caching in the first place. Should people really have to provide menu = {} in order to revert back to setup function defaults for said config? 🙂

[tg0h]

yeah, agree that it's not ideal. Seems like the deep merge function would also be a good excuse to have a go at implementing unit tests ... #30 ... will get round to it if I get round to it :)

[jesseleite]

[ThePrimeagen]

i am very worried about merging this one. I don't want anything to break others using it.

I like the fix, but it makes me much scared :)

[ThePrimeagen]

btw, why is the lsp changing the directory? My guess is that its not the LSP, its your setting (its a vim setting, something like autocd)

[tg0h]

Yups understand the concern, is there anything that can be done to reduce the risk? I suppose we'll need a test suite to really move forward with this ... when we get round to it!!! I am much sad though, was hoping to get my first open source PR merged :))

Not too sure why lsp was changing the directory, from my recollection of my debugging then:

• after removing the child project tsconfig.json/package.json? lsp would no longer change the directory but go to definition no longer works
• I also tried changing the rootDir setting in the child repo tsconfig.json, but I think it also messed up my go to definition...

could be an autocd-ish option hmm will have to investigate ¯_(ツ)_/¯

[matu3ba]

I don't know if this works with git worktrees ... I never could get your git worktrees plugin to work ... someone test ? :D

I can test this. I use scripts to manage git worktrees.

Can you give me some pointers how to workaround .gitignore only for my repo paths for the usual plugins (fd,ripgrep etc that are used within telescope) ? I need to start them from the correct subdirectories of the "currently used worktree".

My main problems are that I need different cwd to run different stuff and harpoon or git-worktree should offer functions to 1. run scripts based on the relative position (and if necessary, cd to saved CWD on exit), 2. have a command history I can copy the used functions and 3. allow to edit the command history.

Accessing the shell history kinda doesnt work and calling scripts from relative position is painful.

[matu3ba]

@tg0h If you are interested I can post an obfuscated version of the test stuff I use at work, which uses git worktrees.
I found git-worktrees relative redundant to storing and using the info explicit in python scripts (with a public struct hack),
but I did not add an editing capability to read and write the config as json yet.

[matu3ba]

I think once this plugin for telescope can store project paths in a scratch buffer, it would solve the use case significantly (with some tweaks for custom actions):
princejoogie/dir-telescope.nvim#1

The better alternative for most use cases is to have completely different views defined with the session system that can be switched to upon opening the path to the vendored git worktree inside the base dir, all available from a project local scratch buffer.