helm-find-files fails with "Text is read-only" when the current path does not fit the frame when helm-echo-input-in-header-line is t

[kassick]

What happened?

When the full file path does not fit the current frame and helm-echo-input-in-header-line is t, trying to navigate up the file tree with helm-find-files fails with Text is read-only .

Oddly enough, this only happens after a new frame is created -- helm works perfectly with the long file name at the first frame you open it, but after creating a new frame, helm-find-files starts failing on all frames.

Maximizing the current frame usually fixes the issue (as long as the path does fit inside the resized frame)

With (setq helm-echo-input-in-header-line nil) I could not observe the issue.

I was only able to reproduce on emacs-29 (currently at 6c86faec29e7e9f12b71886dc66b62e1da43cdf7, but I've been observing the issue for a while now).

Emacs-28.1 (as packaged by Fedora) did not present the issue

---

Minimal init.el used for the tests:

(eval-when-compile
  (require 'use-package))

(use-package helm
             :ensure t
             :bind ("C-x C-f" . helm-find-files)
                   ("M-x" . helm-M-x)
             :config
             (setq helm-echo-input-in-header-line t) ;; this triggers the bug
             (helm-mode 1))

---

Installed packages:

• helm 3.9.0
• helm-core 3.9.0
• popup-0.5.9
• async-1.9.7
• bind-key-2.4.1
• use-package-2.4.4

---

Video reproducing the issue:

Gravacao.de.tela.de.2022-12-27.15-50-07.webm

---

Backtrace when the issue happens:

How to reproduce?

• Compile emacs from the emacs-29 branch
• Start emacs with helm-echo-input-in-header-line set to t
• Open a file that is deep inside a file tree (the full path must not fit inside the current frame width)
• Create a new frame
• Call helm-find-files
• Try to navigate up the tree (C-l or arrow left in the vanilla setup)

Expected result: Helm navigates to the parent folder

Observed result: a Text is read-only message, the cursor in an odd place in the helm window and eventually helm presents the files on the root folder

Helm Version

Melpa or NonGnuElpa

Emacs Version

Emacs-28/29

OS

GNU/Linux

Relevant backtrace (if possible)

Debugger entered--entering a function:
* message("%s%s" "helm-find-files-up-one-level: " "Text is read-only")
  apply(message "%s%s" ("helm-find-files-up-one-level: " "Text is read-only"))
  minibuffer-error-function((text-read-only) "" helm-find-files-up-one-level)
  helm-read-from-minibuffer("Find files or url: " "/home/kassick/tmp/emacs-vanilla/nullam/eu/ante/vel..." "^[[:multibyte:] ]*some_file\\.txt" nil nil "/home/kassick/tmp/emacs-vanilla/nullam/eu/ante/vel..." nil)
  helm-internal(helm-source-find-files "/home/kassick/tmp/emacs-vanilla/nullam/eu/ante/vel..." "Find files or url: " nil "^[[:multibyte:] ]*some_file\\.txt" "*helm find files*" nil "/home/kassick/tmp/emacs-vanilla/nullam/eu/ante/vel..." nil)
  helm(helm-source-find-files "/home/kassick/tmp/emacs-vanilla/nullam/eu/ante/vel..." "Find files or url: " nil "^[[:multibyte:] ]*some_file\\.txt" "*helm find files*" nil "/home/kassick/tmp/emacs-vanilla/nullam/eu/ante/vel..." nil)
  helm(:sources helm-source-find-files :input "/home/kassick/tmp/emacs-vanilla/nullam/eu/ante/vel..." :case-fold-search smart :preselect "^[[:multibyte:] ]*some_file\\.txt" :ff-transformer-show-only-basename t :default "/home/kassick/tmp/emacs-vanilla/nullam/eu/ante/vel..." :prompt "Find files or url: " :buffer "*helm find files*")
  helm-find-files-1("/home/kassick/tmp/emacs-vanilla/nullam/eu/ante/vel..." "^[[:multibyte:] ]*some_file\\.txt")
  helm-find-files(nil)
  funcall-interactively(helm-find-files nil)
  command-execute(helm-find-files)

Minimal configuration

• I agree using a minimal configuration

[thierryvolpiatto]

Rodrigo Kassick ***@***.***> writes:

What happened? When the full file path does not fit the current frame and helm-echo-input-in-header-line is t, trying to navigate up the file tree with helm-find-files fails with Text is read-only . Oddly enough, this only happens after a new frame is created -- helm works perfectly with the long file name at the first frame you open it, but after creating a new frame, helm-find-files starts failing on all frames. Maximizing the current frame usually fixes the issue (as long as the path does fit inside the resized frame) With (setq helm-echo-input-in-header-line nil) I could not observe the issue. I was only able to reproduce on emacs-29 (currently at 6c86faec29e7e9f12b71886dc66b62e1da43cdf7, but I've been observing the issue for a while now). Emacs-28.1 (as packaged by Fedora) did not present the issue

So you mean it is reproducible on emacs-29+ but not on emacs-28.1? Here I couldn't reproduce on both (28 and 30, last from master). Here what I did: 1) C-x 5 2 => new frame 2) M-: (setq helm-echo-input-in-header-line t) 3) C-x C-f (hff) and navigate to a looong directory and filename and didn't have errors. What did I miss to reproduce? Will try again tomorrow more carefully. Thanks.

…

-- Thierry

[kassick]

So you mean it is reproducible on emacs-29+ but not on emacs-28.1?

Exactly

Here I couldn't reproduce on both (28 and 30, last from master).

I've just compiled from master to make sure -- Still got the same error on 30.

I've tried to follow your steps, got the same results. Are you sure that the full path did not fit inside the current frame without truncating?

The steps-to-reproduce I provided were more on the line of "I'm currently vieweing a file inside a looong path and want to navigate from it". Yours, on the other hand, sounded more like "I'm at my home folder and I'm going to navigate to a file inside a looong path".

Either way, navigating to the looong path also triggered the issue once the path became long enough (like /home/kassick/tmp/emacs-30-vanilla/nullam/eu/ante/vel/est/convallis/dignissim/Fusce/suscipit/wisi/nec/facilisis/facilisis/est/dui) the cursor moves to the beginning of the minibuffer and I get the read-only message. In a 79 char wide frame, the path was truncated at least once before this, without triggering the error. Also, the issue appears more like a transient bug when navigating to the long path -- on several attempts, it correctly navigated up to nullam/eu/ante/vel/est/convallis/dignissim/Fusce/suscipit/wisi/nec/facilisis/facilisis/est/dui/fermentum/leo/quis/tempor/ligula/erat/quis/odio/Nunc/porta/vulputate/tellus/some_file.txt and then back; In others, it would fail at some random point

What did I miss to reproduce?

Maybe the path was not long enough? Maybe it needs to be at least twice the frame width? Maybe the bug is more easilly triggered when navigating upwards from a looong path ?

Here I created a file inside /home/kassick/tmp/emacs-30-vanilla/nullam/eu/ante/vel/est/convallis/dignissim/Fusce/suscipit/wisi/nec/facilisis/facilisis/est/dui/fermentum/leo/quis/tempor/ligula/erat/quis/odio/Nunc/porta/vulputate/tellus and tried to navigate to and from it.

Will try again tomorrow more carefully.

Let me know if you need any other information!

[thierryvolpiatto]

Rodrigo Kassick ***@***.***> writes:

So you mean it is reproducible on emacs-29+ but not on emacs-28.1? Exactly Here I couldn't reproduce on both (28 and 30, last from master). I've just compiled from master to make sure -- Still got the same error on 30. I've tried to follow your steps, got the same results. Are you sure that the full path did not fit inside the current frame without truncating? The steps-to-reproduce I provided were more on the line of "I'm currently vieweing a file inside a looong path and want to navigate from it". Yours, on the other hand, sounded more like "I'm at my home folder and I'm going to navigate to a file inside a looong path". Either way, navigating to the looong path also triggered the issue once the path became long enough (like /home/kassick/tmp/emacs-30-vanilla/nullam/eu/ante/vel/est/convallis/dignissim/ Fusce/suscipit/wisi/nec/facilisis/facilisis/est/dui) the cursor moves to the beginning of the minibuffer and I get the read-only message. In a 79 char wide frame, the path was truncated at least once before this, without triggering the error. Also, the issue appears more like a transient bug when navigating to the long path -- on several attempts, it correctly navigated up to nullam/eu/ante/vel/est/convallis/dignissim/Fusce/suscipit/wisi/nec/facilisis/facilisis/est/dui/fermentum/leo/quis/tempor/ligula/erat/quis/odio/Nunc/porta/vulputate/tellus/some_file.txt and then back; In others, it would fail at some random point What did I miss to reproduce? Maybe the path was not long enough? Maybe it needs to be at least twice the frame width? Maybe the bug is more easilly triggered when navigating upwards from a looong path ?

I could reproduce by using "nullam/eu/ante/vel/est/convallis/dignissim/Fusce/suscipit/wisi/nec/facilisis/facilisis/est/dui/fermentum/leo/quis/tempor/ligula/erat/quis/odio/Nunc/porta/vulputate/tellus/some_file.txt" as current-buffer before starting helm-find-files, I could even reproduce from 28.2 as well; when navigating to the same path from elsewhere i.e. some_file.txt is not the current-buffer, I can't reproduce. If I add helm-hide-minibuffer-maybe to helm-minibuffer-set-up-hook, it fixes the issue, so I have add it by default.

…

Here I had the following setup: Will try again tomorrow more carefully. Let me know if you need any other information! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry

[kassick]

Cool!

I can confirm it fixes in the vanilla setup, but it's still failing in Spacemacs with the same setup. I'll wait for the next release and then open an issue there.

Merci!

[kassick]

I can still reproduce the bug in helm-20230101.1922 (commit 431e34d) with the following setup:

(eval-when-compile
  (require 'package)
  (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
  (require 'use-package))

(use-package helm
         :ensure t
         :bind ("C-x C-f" . helm-find-files)
               ("M-x" . helm-M-x)
         :config
         (setq
          helm-echo-input-in-header-line t ;; this would trigger the bug before; works as expected with the workaround below
          helm-minibuffer-set-up-hook '(helm-hide-minibuffer-maybe) ;; proposed workaround

          helm-display-header-line nil ;; with helm-20230101.1922 this triggers the bug
          )
         (helm-mode 1))

Setting helm-display-header-line to nil causes the bug to surface again. Spacemacs sets this to nil by default -- that's why helm-hide-minibuffer-maybe in the set-up-hook fixed in my vanilla setup at first, but not in spacemacs. Setting it to t in my spacemacs config fixes the issue

[thierryvolpiatto]

Rodrigo Kassick ***@***.***> writes:

I can still reproduce the bug in helm-20230101.1922 (commit 431e34d) with the following setup: (setq helm-echo-input-in-header-line t ;; this would trigger the bug before; works as expected with the workaround below helm-minibuffer-set-up-hook '(helm-hide-minibuffer-maybe) ;;

Always use add-hook to setup a hook, NOT setq.

Setting helm-display-header-line to nil causes the bug to surface again.

Of course, it have to be non nil inconditionally when you use helm-echo-input-in-header-line. I will try to make this clear in docstrings. Thanks.

Spacemacs sets this to nil by default

🙄

…

-- Thierry