-
-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #2663 #2781
base: master
Are you sure you want to change the base?
Fix #2663 #2781
Conversation
Not working with copy-sequence. I have no idea why |
What isn't working exactly? What about |
Most tests fails with copy-squence or copy-alist but everything passe with copy-tree. From the copy-tree's docs
|
That's expected, because
That's because That means this PR is a no-op, so I'm wondering which issue it's trying to solve, and whether it's an issue at all. |
When you invoke counsel-M-x and you type ^ev buf and select eval-buffer in the history there will be eval-buffer then ^ev buf which I find not really convenient. An easy way to fix it is to set history-add-new-input to nil so you'd have only ^ev buf added to the history. But if let's say I don't use counsel for a command then I'll have no history at all for that command. I'm just trying to find a way to remove the eval-buffer while keeping history-add-new-input to true. I think when I created this PR I've lost myself a bit and yeah, my method is definitely not working... |
I agree, but I'm not sure whether @abo-abo introduced this intentionally.
What if some users prefer the opposite: to keep So I think this behaviour should be customisable somehow. |
All right after some testing I found out we just need to
(setq history-add-new-input nil)
and no modifications to ivy--update-history.Ivy-read calls read-from-minibuffer which will add the selection to history if history-add-new-input is non-nil.
My issue is gone and the test are ok.
But now it will break some workflow like if someone prefer let's say find-file instead of counsel-find-file the history won't work. It's not really efficient but as a workaround instead of passing the real hist var to read-from-minibuffer we can pass a copy of it and so we can leave history-add-new-input as it is.