helm completion exit-minibuffer duplicates some already-entered text

[wwade]

What happened?

I'm trying to run an Async shell command, e.g. git checkout refs/meta/config. When I start with git checkout refs/met then TAB, it shows me two options in the completion minibuffer, so I select config and then the completion becomes git checkout refs/refs/meta/config.

I expected to just see refs/meta/config, that is the entire completion without extra refs/ prefix.

	minibuffer contents
expected	git checkout refs/meta/config
actual	git checkout refs/refs/meta/config

The problem seems to have first appeared with the fix for #2504 - git bisect landed me at commit 452dd1b.

How to reproduce?

Repro steps

Using my minimized init.el (straight + bash-completion + helm, see below), I start emacs and then

1. M-& for async-shell-command
2. type git checkout refs/met + TAB
3. ENTER to select refs/meta/config from the helm-mode-completion-at-point menu

The minibuffer contents are now git checkout refs/refs/meta/config.

min init.el

(setq package-enable-at-startup nil)
(setq straight-use-package-by-default t)

(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 5))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

(straight-use-package 'use-package)
(straight-use-package 'bash-completion)

(require 'bash-completion)
(bash-completion-setup)

(use-package helm :init (progn (require 'helm-config) (helm-mode)))

Helm Version

Master branch

Emacs Version

Emacs-27.2

OS

GNU/Linux

Relevant backtrace (if possible)

No response

Minimal configuration

• I agree using a minimal configuration

[thierryvolpiatto]

wwade ***@***.***> writes:

What happened? I'm trying to run an Async shell command, e.g. git checkout refs/meta/config. When I start with git checkout refs/met then TAB, it shows me two options in the completion minibuffer, so I select config and then the completion becomes git checkout refs/refs/meta/config. I expected to just see refs/meta/config, that is the entire completion without extra refs/ prefix. minibuffer contents expected git checkout refs/meta/config actual git checkout refs/refs/meta/config The problem seems to have first appeared with the fix for #2504 - git bisect landed me at commit 452dd1b. How to reproduce? Repro steps Using my minimized init.el (straight + bash-completion + helm, see below), I start emacs and then 1. M-& for async-shell-command 2. type git checkout refs/met + TAB 3. ENTER to select refs/meta/config from the helm-mode-completion-at-point menu The minibuffer contents are now git checkout refs/refs/meta/config. min init.el (setq package-enable-at-startup nil) (setq straight-use-package-by-default t) (defvar bootstrap-version) (let ((bootstrap-file (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory)) (bootstrap-version 5)) (unless (file-exists-p bootstrap-file) (with-current-buffer (url-retrieve-synchronously "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el" 'silent 'inhibit-cookies) (goto-char (point-max)) (eval-print-last-sexp))) (load bootstrap-file nil 'nomessage)) (straight-use-package 'use-package) (straight-use-package 'bash-completion) (require 'bash-completion) (bash-completion-setup)

I guess this a bash-completion bug, not helm.

(use-package helm :init (progn (require 'helm-config) (helm-mode))) Helm Version Master branch Emacs Version Emacs-27.2 OS GNU/Linux Relevant backtrace (if possible) No response Minimal configuration • [*] I agree using a minimal configuration

You are not using actually a minimal configuration.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.*Message ID: ***@***.***>

-- Thierry

[wwade]

So I had to have something to provide the completions for it to work off to reproduce the issue at all, and so I it was the minimal configuration possible to see the issue.

I guess it's an interaction issue, because I don't see the issue using only bash-completion on it's own.

Any thoughts on a way to debug this further, or to separate the two pieces?

As I mentioned, I don't see it with helm versions earlier than that commit. I started bisect from helm 3.7.0.

[wwade]

I tried again just now using only helm and this simple completing-read, and it didn't happen there. I can see what you mean about it likely being something with bash-completion, though, in the way that it does have to parse the tokens separately, etc. This simple one didn't work. I probably need to use a function for completing-read, at the least:

(completing-read "> " '("hello" "refs/meta/config" "refs/meta/something"))

[thierryvolpiatto]

wwade ***@***.***> writes:

I tried again just now using only helm and this simple completing-read, and it didn't happen there.

This is not the same beast, the bug here is in completion-in-region for this particular case i.e. A file completion which is not really a file completion because we are completing .git/ directory from elsewhere, which confuse pcomplete. I am trying actually to find a compromise to make things working in all cases but it is not easy. Thanks.

…

-- Thierry

[thierryvolpiatto]

wwade ***@***.***> writes:

So I had to have something to provide the completions for it to work off to reproduce the issue at all, and so I it was the minimal configuration possible to see the issue. I guess it's an interaction issue, because I don't see the issue using only bash-completion on it's own. Any thoughts on a way to debug this further, or to separate the two pieces? As I mentioned, I don't see it with helm versions earlier than that commit. I started bisect from helm 3.7.0.

I have reverted this commit for now until I find a better solution.

…

-- Thierry

[wwade]

Alright, thanks a lot for the help here, it's much appreciated.

[thierryvolpiatto]

I think this has been fixed, closing now, feel free to reopen if still happen. Thanks.