repo is not cloned in the selected path
benthamite opened this issue · comments
Describe the bug
consult-gh-repo-clone
does not clone repos in the selected path.
To Reproduce
Steps to reproduce the behavior:
M-x consult-gh-repo-clone modus-themes
RET
in the first candidate (protesilaos/modus-themes
)- Select a target directory, e.g.
~/source/
, and confirm. - The directory in instead cloned in the current directory, e.g.
~/Downloads/
.
Expected behavior
The repo is cloned in the selected path.
Important Information:
- macOS Sonoma 14.2.1
- GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin22.5.0, NS appkit-2299.60 Version 13.4.1 (c) (Build 22F770820d)) of 2023-08-27
- gh version 2.40.1 (2023-12-13)
https://github.com/cli/cli/releases/tag/v2.40.1 - consult version 1.1
config:
(use-package consult-gh
:elpaca (consult-gh
:host github
:repo "armindarvish/consult-gh")
:after consult forge
:demand t
:config
(require 'consult-gh-embark)
(require 'consult-gh-forge)
(setq consult-gh-default-clone-directory "~/source/")
(setq consult-gh-repo-maxnum 30)
(setq consult-gh-issues-maxnum 100)
(setq consult-gh-show-preview nil)
(setq consult-gh-preview-key 'any)
(setq consult-gh-preview-buffer-mode 'org-mode)
(setq consult-gh-repo-action #'consult-gh--repo-browse-files-action)
(setq consult-gh-issue-action #'consult-gh-forge--issue-view-action)
(setq consult-gh-pr-action #'consult-gh-forge--pr-view-action)
(setq consult-gh-code-action #'consult-gh--code-view-action)
(setq consult-gh-file-action #'consult-gh--files-view-action)
(setq consult-gh-issues-state-to-show "all")
(dolist (var '(consult-gh--known-orgs-list
consult-gh--known-repos-list))
(push var savehist-additional-variables)))
@benthamite cannot reproduce this either. can you share screenshots?
From what you describe, it seems like your directory selection is not working, that is likely not a consult-gh related issue, so I need to see how you are doing the path selection before I can help.
Hi @armindarvish,
Thank you for answering.
You can find a short video recording here. Let me know if you need further information.
@armindarvish thank you for this awesome package, I really like the way it will change my workflow.
I had the same issues, I made a small change to the consult-gh which worked for me. I suspected it had something to do with my consult, orderless, vertico, embark setup but did not know where to start. I figured out while writing this that I just need to add vertico to my :after list :after (consult embark transient vertico)
in my use package declaration for consult-gh. I include the modified function in the hope someone can use it temporarily.
(defun consult-gh-repo-clone (&optional repos targetdir)
"Interactively clone REPOS to TARGETDIR. This is a temporary override of the library func with one fix in the read-directory-name call"
(interactive)
(let* ((consult-gh-prioritize-local-folder (if (eq consult-gh-prioritize-local-folder 'suggest) consult-gh-prioritize-local-folder nil))
(repos (or repos (substring-no-properties (car (consult-gh-search-repos nil t)))))
(targetdir (or targetdir consult-gh-default-clone-directory))
(clonedir (if consult-gh-confirm-before-clone (read-directory-name "Select Target Directory: " targetdir nil t) targetdir)))
(if (stringp repos)
(setq repos (list repos)))
(mapcar (lambda (repo)
(let* ((package (consult-gh--get-package repo))
(name (if consult-gh-confirm-before-clone (read-string (concat "Name for " (propertize (format "%s: " repo) 'face 'font-lock-keyword-face)) package) package)))
(consult-gh--repo-clone repo name clonedir))) repos)))
Thanks, @heigum.
I can confirm that the repo is cloned in the correct directory with your function.
Adding vertico
to :after
doesn’t fix the issue, though.
@benthamite and @heigum
Can you please remove the trailing "/" in your consult-gh-default-clone-directory
and try again?
That would be use:
(setq consult-gh-default-clone-directory "~/source")
Hi @armindarvish,
This worked. I find this a bit puzzling since I was still presented with a completion menu and ended up selecting the same directory. In other words, removing the trailing slash changed the initial completion input, not the directory selection. In fact, it also works if one sets consult-gh-default-clone-directory
to any arbitrary directory, e.g. ~/Downloads
, as long as one selects source
in the completion menu.
Without the trailing /
it works fine, however I do have to select the last path element before I can clone. I have ~/projects/github
so the selection ui looks like this, pressing RET
twice clones into correct dir.
And disregard my comment that it worked after adding vertico to my after list. I had my function def still active, so I fooled myself...
With my version of the function it behaves the same without the trailing /
and I get away with one RET
if I add it.
@benthamite I committed a better general fix in develop branch that should also work with the "/".
The issue was with read-directory-name
behavior. For some reason it fails when both a trailing "/" is present in the DIR input and a DEFAULT-DIRNAME was provided as well! Also, what you described is the intended behavior. The completion menu uses consult-gh-default-clone-directory
as the initial selection but allows you to select whatever path you wish. If you want you can set consult-gh-confirm-before-clone
to nil
and then you won't be asked to confirm the path or name. It will automatically clone the repo in the path you set with consult-gh-default-clone-directory
under the same name as the repo.
@heigum I don't have to press "RET" twice. That is likely caused by some other settings in your setup. May be check the value of insert-default-directory
or your vertico config!
Also, your version of that function causes some other issues that is not suitable for a general solution. For example, you are passing t
to MUSTMATCH
in read-directory-name
which means the user cannot choose/make a previously non-existing folder as target for cloning.
Either way you can also try the new commit in develop branch and see if this solves the issue for you. Otherwise you can always override that function with your own version.
@armindarvish tested with the function version you have on the develop branch, that works perfectly.