After using C-x C-s I see
indenting region done.
in the minibuffer and all my changes are not saved.
My crystal ball tells me you have something like
(add-hook 'write-file-functions <something-that-reindents-buffer>)
somewhere in your ~/.emacs. write-file-functions is a hook to let you change the way something is written, but it's often been abused to just do something before writing the file.
A function on write-file-functions should indicate whether it did write the file or not, by returning either nil or non-nil, and my crystal ball thinks that <something-that-reindents-buffer> happens to return a non-nil value.
If my crystal ball got it right, the fix would be to use before-save-hook instead.
Related
Sometimes when in comint mode the point is anywhere in the buffer and I press Return by mistake. This sends the text at point to the underlying process, which can be really dangerous. Often this text contains many lines and, by chance or not, one of them could be a valid command.
Is there any way to tell comint not to execute anything on Return except the last input?
The documented way seems to be override comint-get-old-input variable with a custom function. Easiest will be something like this:
(setq comint-get-old-input (lambda () (end-of-buffer) (comint-get-old-input-default)))
It goes to the end of buffer first, and only then calls coming-get-olt-input-default, effectively not messing with the previous output. Put it in your init.el, brief testing shows that it works.
I'd like to know if there's some way not be prompted with: "Buffer changed, save first? (y or n)" everytime I execute the buffer [C-c C-c] after some change. I came across the variable py-ask-about-save, which has the following documentation:
If not nil, ask about which buffers to save before executing some code.
Otherwise, all modified buffers are saved without asking.
which is a behavior I could accept. However
(setq py-ask-about-save nil)
has no effect. Is there some other thing I should be aware of?
Indeed, it would be even better if C-c C-c had no effect saving any buffer, but only be responsible for executing the code.
The variable py-prompt-on-changed-p appears to be what the O.P. is seeking. The doc-string states:
When called interactively, ask for save before a changed buffer is sent to interpreter.
See also line 10284: http://bazaar.launchpad.net/~python-mode-devs/python-mode/python-mode/view/head:/python-mode.el
I'm probably going down the wrong path here, so let me know if I am. I'm trying to build a similar user interface to that which Vim's ctrlp and other plugins use, whereby the user is given a prompt, and as they type, results are shown above the minibuffer prompt line.
I've gotten the minibuffer command handling part working fine with minibuffer-with-setup-hook and a local post-command-hook (easy) and can get the results I want to display (verified by just (message)ing them for now).
If I want to show, say, 10 lines of results above that minibuffer prompt line, should I be somehow prepending text to the minibuffer, or using a separate buffer that I'll close once the command finishes? Any pointers to parts of the manual I should be reading to be on the right track with this?
The "minibuffer" is a normal buffer, so you can modify it by inserting/deleting text into it in the normal way. This said, adding text "before" means basically modifying the prompt which might lead to problems down the line. You'll probably be much better off doing something like
(let ((ol (make-overlay (point-min) (point-min))))
(overlay-put ol 'before-string (format "%s\n" myresults)))
I started to write this as a comment, but it got a bit too long ...
TBH, I feel there is room for a lighter weight version of helm. But the reality is helm is good enough, and someone else has already written it.
Neither I nor anyone else (so far) is motivated enough to rewrite it. What you describe as "God" aspect of it is indeed unappealing. But it is possible to load it (huge as it is, with modern computers, it really isn't an issue), and change settings so it is minimalistic.
ido is a simpler alternative, but the style of UI is not exactly how you described.
When editing an Rnw file in Emacs, I often want to make the region cover a chunk of text that contains an R chunk. For a simple example:
ewr
<<>>=
#
wer
I use transient-mark-mode such that the region is highlighted. But, if I put the point on the first line and hit C-SPC, then use C-n to move the point down, the highlighting disappears when I try to advance the point past the <<. The region I want is still selected, but highlighting seems to fail when crossing the <<. How can I fix this?
Thanks and best regards
I find that your problem shows up when I do what you describe, but it goes away if you scroll down using C-down or C-M-n instead. I think you can even use C-down to get past the R chunk and then C-n to step past lines afterward.
I had the same problem and the solution suggested by fojtasek did not work for me because I had an additional configuration problem. I hope that this might be useful for you and other users. Make sure that if you are using ESS and Auctex that you have fully loaded Auctex. To be more specific, it turned out that when I had previously installed auctex 11.86, I did not correctly load the package. Because I am a novice emacs user, I only managed to load the first of the following two lines:
(load "auctex.el" nil t t)
(load "preview-latex.el" nil t t)
If you have not added the second line, you will only have an Auctex menu but NOT a preview-latex menu.
Thanks to Fojtasek for the C advice. I find C- with the arrow key will keep a contiguous highlight. C-down brings up a page that says "this confusing feature has been disabled by default".
In my opinion, this behavior that OP complained about is a flaw in Auctex, and the fact that Fojtasek has a way to avoid it is helpful, but still it is just a workaround. I don't want Auctex to to this and I don't really want to have to use my left hand for holding down C while scrolling. PITA.
If Auctex needs some special selection tool, they should have to use unusual keystrokes for that. Why impose it on the rest of us who just want to highlight big sections and move them around, whether or not they have <<>> in them.
It often occurs that a file buffer is modified (duh!). Before exiting, emacs asks whether to save the changes. Now it would be interesting to know what actually changed. Is there a way to find out?
As of Emacs 22.1 (at least), 'save-buffers-kill-emacs (the default binding for C-x C-c) prompts you for each unsaved buffer that has a file. Type a d when prompted to save and see the diff.
From the help documentation:
Save some modified file-visiting buffers. Asks user about each one.
You can answer `y' to save, `n' not to save, `C-r' to look at the
buffer in question with `view-buffer' before deciding or `d' to
view the differences using `diff-buffer-with-file'.
If you look at the prompt, it should say something like:
Save file /path/to/file.txt? (y, n, !, ., q, C-r, d, or C-h)
Typing C-h gives you a little more verbose description (but d is what you are asking for):
Type SPC or `y' to save the current buffer;
DEL or `n' to skip the current buffer;
RET or `q' to give up on the save (skip all remaining buffers);
C-g to quit (cancel the whole command);
! to save all remaining buffers;
C-r to view this buffer;
d to view changes in this buffer;
or . (period) to save the current buffer and exit.
I use diff-buffer-with-file, and select the file that the buffer came from (which is the default anyway for the command... just hit enter).
You can also use highlight-changes-mode, though this won't track changes until you turn it on, so not so useful if you want to see what changed when you're closing a file that has not been in this mode :-)
You can have highlight-changes-mode enabled. It will display all changes in red. However it won't show you whitespace changes and will mark removals only with an red _. See also http://www.emacswiki.org/emacs/TrackChanges.
I found this post about tracking changes by djcb most helpful regarding tracking changes in Emacs. The trick is to add the following to your .emacs:
;; higlight changes in documents
(global-highlight-changes-mode t)
(setq highlight-changes-visibility-initial-state nil); initially hide
and then toggle highlight-changes-visible-mode when you want to see what has changed.
In this case I type undo to see the last change (usually some stray character which got typed in the wrong window, since I save early and often).
It would be nice if there were some other indication of the current changes, e.g. in the border like quick diff in Eclipse text editors.
I use goto-chg for things like that. It's not perfect, but it always is enough to jog my memory about what change I made and promptly forgot about.