I would guess that's a result of one specific persistent variable getting enormous (it just seems less likely that you would have multiple instances at the same time), but if you've deleted the file you can't see which variable it was.
You can always rename the file rather than deleting it, so that you can make Emacs happy again, but still analyse the data.
I can add not an exact answer to your question, but a workflow that eliminates the need for it.
I use smex instead of execute-extended-command.
Once in the minibuffer of smex:
RET calls execute-extended-command
C-h f calls smex-describe-function
M-. calls smex-find-function
I don't like the default bindings, so I've customized them:
The "easiest way" is to just define your own version of describe-function, and bind that to C-h f.
Take the vanilla code, and change only the call to completing-read so that it uses the same history list that M-x (execute-extended-command) uses, which is extended-command-history.
(defun my-describe-function (function)
"Display the full documentation of ...
Please note that it's very easy to invoke the command from its Help buffer. After typing C-h f just type M-x M-n RET. This works because in a new Help buffer the command name is at the top of the buffer under the cursor, and M-n retrieves it to the minibuffer.
However, if you want to add a command to extended-command-history every time you visit its ...
You can save the buffer-local value of comint-input-ring in a global variable when an *ielm* buffer is killed and restore it in inferior-emacs-lisp-mode-hook:
;; global copy of the buffer-local variable
(defvar ielm-comint-input-ring nil)
(defun set-ielm-comint-input-ring ()
;; create a buffer-local binding of kill-buffer-hook
Load library Bookmark+ and use a variable-list bookmark.
A variable-list bookmark saves and restores the values of a set of variables.
prompts you for the variables to include in the list and then sets the bookmark. Non-interactively, you can use function bmkp-create-variable-list-bookmark to create or update a ...
I think what you might do is to use properties of the variable symbol to store the history.
That is, each symbol can have a property list, which is a list of pairs. The key will be major mode names, and value the history as list you wanted.
But i don't know if that's efficient enough to work out.
The savehist library provides one option for persisting variable values across sessions. e.g.:
'(add-to-list 'savehist-additional-variables 'foo))
As with customize, that's writing everything to a single specific file. But there's no reason why you couldn't leverage this library's functionality by let-...
A variable is either buffer-local or not. If it's buffer-local then the value isn't shared with other buffers. There's no built-in feature to directly have a variable that's shared between buffers. So you'll need to do something where accessing the value of the variable isn't just my-variable and setting isn't just (setq my-variable some-value).
Setting comint-input-ring-separator so that the whole timestamp is treated as part of the command separator worked for me. For example:
; Remember lots of previous commands in shell-mode
(setq comint-input-ring-size 100000)
(add-hook 'shell-mode-hook 'my-shell-mode-hook)
(defun my-shell-mode-hook ()
(setq comint-input-ring-file-name "~/.zsh_history")
Commands that read input from the minibuffer use functions such as completing-read, read-string, read-regexp, etc. The most general of these is read-from-minibuffer.
All such functions take a HISTORY argument, which is a variable whose value is a list of previous inputs read by the function. If HISTORY is absent or nil then usually the variable is ...
You could use read-string and give they default value def-say-word and save in later.
(setq def-say-word "default value")
(defun say-word (word)
(list (read-string (format "Say word [%s]: " def-say-word) nil nil def-say-word)))
(setq def-say-word word)
(message "The word is %s" word))
Your question is s bit unclear to me.
Multi-command icicle-insert-history-element (bound to M-o) is for inserting previous inputs into the active minibuffer using completion, appending them individually to whatever is already in the minibuffer.
If you want to see all previous (i.e., history) inputs for a given minibuffer history (e.g., a command history) ...
If you are looking to have commands that you previously entered at the M-x prompt available as completion candidates, then Icicles can help.
There are several ways in which you can use completion against candidates from minibuffer histories. One simple one is to use M-h. For example, M-x M-h shows your M-x inputs in buffer *Completions*. You can type text ...
Looks like you already use helm - as you gave the example of helm-occur. Helm comes with helm-minibuffer-history - try
The usual way of selecting helm candidates works here too.
These files (COMMIT_EDITMSG, git-rebase-todo and others) are added to file-name-history by server-visit-files. It is possible to undo that by advising that function, and I have implemented that.
But I am unsure whether that advise should also remove entries for these files that already existed prior to that function being called. I think so because those ...
Based on the comments to my question, I was able to come up with a (partial?) solution:
Create a list of variables with sensitive information.
Create a function that makes them local to a buffer.
Create another function that sets them to nil.
Add a find-file-hook to conditionally call the first function.
Add a kill-buffer-hook to conditionally call the ...
If you use helm-M-x, there is no need to type C-h f to look up commands's documentation, just use C-j or C-z while running helm-M-x to toggle the display of documentation.
See also Helm M-x's features.