When some key sequence triggers an unexpected command, use view-lossage (bound to C-h l by default) to see what keystrokes Emacs has recently received. This is most useful since Emacs 25 as it now also shows the commands invoked by each key sequence. In earlier releases you'll just see the raw keystrokes.
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.
Indeed, if helm-ff-file-name-history-use-recentf set to true, helm-find-files is supposed to use recentf-list instead of file-name-history.
To enable the recenf minor mode, I have those lines in my init file:
; keep a list of recently opened files
Perhaps this isn't quite what you're looking for, but I really like using helm-mini, which includes a small browser for recent open files (by calling helm-recentf as Nsukami suggests you use). Here is an example, taken from this amazing post on helm:
Not only does it show all of your open buffers, but it's my most convenient way to view recently opened ...
As @glucas has mentioned, view-lossage helps. Unfortunately, it displays relatively few events, and users have no control over the number.
As C-h k C-h l tells you, you can record all keyboard characters by using open-dribble-file:
view-lossage is an interactive compiled Lisp function in help.el.
It is bound to C-h l, <f1> l, <help> l.
"Yank" is just English. You are "pulling" some text into the current buffer at point.
Note that the more common term "paste" (no, it is not quite the same thing) is no clearer in this regard. There is no glue involved.
Note too that the verb "copy" has two meanings that can confuse its use. One of them means to make an invisible copy, which can later be ...
Magit recently gained support for something like this, but the feature is still a bit rough around the edges and has to be enabled explicitly.
A similar feature has existed for a long time - when you move from one commit to another in a log buffer, and another window in the same frame is the repository's revision buffer, then that buffer is refreshed to ...
You can use kill-buffer-query-functions to prevent certain buffers from being killed inadvertently. I use something like this:
(defcustom buffer-protect-buffers '("*scratch*" "*Messages*")
"List of buffer names to protect."
:type '(repeat string)
(defun buffer-protect-protected-p (buffer)
"Return non-nil if BUFFER is ...
This is a general Lisp question - a question about Lisp lists. It is not special to Emacs Lisp.
The answers you are getting are all correct, and they say the same thing, so far. You apparently don't want to hear the answer. ;-) And no, they are not just rephrasing your question.
The answer is, as others have said, that the return value is useful beyond ...
Others will no doubt provide different solutions. Here's mine, from library misc-cmds.el.
(defun repeat-command (command)
(let ((repeat-message-function 'ignore))
(setq last-repeatable-command command)
Then just define a new, repeating command for any non-repeating command, and remap the keys from the non-...
You're looking for the commands comint-previous-matching-input-from-input and comint-next-matching-input-from-input, which by default are bound to C-c M-r and C-c M-s.
I recommend binding these command to M-p and M-n, like so:
;; originally on C-c M-r and C-c M-s
(define-key comint-mode-map (kbd "M-p") #'comint-...
Lisp error: (invalid-read-syntax "#")
At the core it is obvious what is happening here.
Something reads a string from a Magit buffer and does not remove properties.
That string is given to completing-read, or similar, as INITIAL-INPUT, DEF, or a member of COLLECTION. completing-read does not remove the properties, you select the propertized string, and it ...
It sounds like you should start, as others have said, by getting to know (well) desktop.el. Add to that savehist.el and saveplace.el. Others may have other suggestions.
savehist.el will take care of histories and rings (they are variables), including command histories (command-history, extended-command-history ...).
The built-in library saveplace.el contains a commentary that states:
;; Automatically save place in files, so that visiting them later
;; (even during a different Emacs session) automatically moves point
;; to the saved position, when the file is first found. Uses the
;; value of buffer-local variable save-place to determine whether to
;; save position or ...
Emacs is a derivative of TECO. The history is long and complicated, and I don't have much first-hand knowledge of it, but TECO had a Kill command for removing text from the buffer. This is documented in a TECO manual that a quick search turned up: http://www.copters.com/teco.html#RTFToC31. At some point the kill-ring was added to Emacs for storing recently-...
I don't know if there's a command history proper, but there's a minibuffer history. The manual says the following about it:
Every argument that you enter with the minibuffer is saved in a
“minibuffer history list” so you can easily use it again later.
Emacs keeps separate history lists for several different kinds of
arguments. For example, ...
When you use the minibuffer, C-r is not bound to isearch-backward. You are not using Isearch at that time, and Isearch does not use the minibuffer, even though it might look like it does.
Perhaps you really mean M-r in the minibuffer, which is previous-matching-history-element and which completes against the current minibuffer input history.
In Isearch you ...
You should be able to save it to a file just like any other buffer - switch to it with C-h e and then save it to a named file with C-x C-w. This will save the current contents of the buffer but note that as it continues to update those changes won't appear in the saved file. If you really wanted to save it all (although I'm not really sure why this would ...
I wasn't in their head when the original coders of those Lisp primitives made this choice, but my guess is that it seemed like the most useful non-nil value to return among those that were available without doing any extra work.
IOW somewhere along the lines of "keeping the number of C-primitives low by adding semantics to the non-false return values", ...
Disclaimer: I don't use eshell, so take this with a grain of salt.
eshell appears to call eshell-write-history to write history, which takes an optional argument append which defaults to nil. This argument seems to be unused in eshell presently, but does appear to work (it passes the argument through to write-region, which does properly append).
There are ...
(Your question must be about the keyboard, not the terminal, I think.)
Emacs was written by multiple people, from the outset. And at that time there were multiple kinds of keyboards (but they were generally QWERTY). Emacs was developed on keyboards similar to those on which vi was developed.
The essential difference between vi and Emacs, and the reason ...
The command won't be placed into your command history until after it is run, and since the command kills emacs, that never happens.
You can counter this by killing emacs only after the command has ran and the call stack clears by running kill-emacs on a 0 second timer.
The call to (kill-emacs) would then be replaced with this:
(run-with-timer 0 nil (...
Yank's meaning comes from English language's action verbs similar to jerk, pull, draw, force, etc. It is a more active verb than copy, paste, and other modern synonyms GUIs use. Please refer to other other responses to this question for its semantic history.
There is one important functional history of yank that many modern uses of copy-and-paste ignore ...
It's not a side effect, it's the return value of the function.
Every function returns something. In elisp, every non-nil
value (and (eq nil '()) returns t) is treated as a boolean
true. So rather than suppress information by returning t, the
function gives you the list from the matching element on, which
you are free to use or discard as you see fit.