I'm just getting started with magit.
I really like it, except that the diff viewer is really annoying to me. The chunk highlighting makes no sense because as I scroll around the cursor moves with the screen, highlighting new regions. There is also no other syntax highlighting in the magit diff mode. Does anybody know how to disable the chunk highlighting and get better diff colours other than white on gray?
Thanks.
This is an issue with Magit in combination with Emacs standard theme "wombat".
To work around this, do
M-x customize
Search for magit-item-highlight, click Show All Attributes, uncheck Inherit, then Save and Apply (or maybe only apply).
You lose the highlighting of the current hunk of the diff, but you can tell that still from the hunk's heading anyway, so it was somewhat redundant. Otherwise it resolves the issue nicely.
The zone highlighted correspond to the stash that would be staged when you hit "s".
Inside the hunk, the diff should be colored. You could test the development version (see https://github.com/magit/magit), and if this doesn't solve your issue, add comment in https://github.com/magit/magit/issues/133 about your configuration and exact problem.
There should be a customize group magit which allows you to customize all the different faces for the diff viewer.
In other words, you can run
M-x customize-group RET magit-faces RET
to see a list of all the faces used by Magit. The ones relevant to the diff viewer are, of course, the ones starting with Magit Diff.
Simply customize away and select Apply and Save. Alternatively, you can just use the Customize interface to see what faces are available, and then set them directly using set-face-foreground, set-face-background, and so on in your init-file.
If you're running the latest 1.0 version, you can also navigate to any of the diff chunks, hit the 'e' key to get an ediff presentation of the differences.
If you don't want to try M-x customize for some reason, simply place the following snippet in your init.el
(defun disable-magit-highlight-in-buffer ()
(face-remap-add-relative 'magit-item-highlight '()))
(add-hook 'magit-status-mode-hook 'disable-magit-highlight-in-buffer)
Source: https://github.com/magit/magit/issues/133
Related
I am currently using spacemacs with auctex. When I use reftex-toc and goto an item then it performs a vsplit and shows the content in the right window. How do I prevent this splitting behaviour? I would like it to open in the current buffer from which the command was issued.
It is related to reftex-toc.el.
I added this hook to maximize the newly opened window:
(add-hook 'reftex-toc-mode-hook 'spacemacs/toggle-maximize-buffer)
but it is a suboptimal solution, as it influences other splits I might have made.
What you describe could be related to the way you select an item.
In normal Emacs (not Spacemacs), I see that SPC is bound to reftex-toc-view-line which behaves just how you describe it. But RET is bound to reftex-toc-goto-line-and-hide which seems to do what you want.
Maybe you just need to find out where that function is on your keymap.
I enjoy using magit and whenever I have to look at a diff outside of magit, it
occurs to me how inferior the default diff experience is.
Two aspects in particular:
1) refine diff automatically as I move into new hunks.
- diff-auto-refine-mode is not a substitute because I don't always move
with M-p and M-n.
2) white space differences are really obvious because
magit-whitespace-warning-face face is applied.
Is there a way to get these two features in diff-mode
I think sending a message to the Magit maintainers asking them to submit those changes for inclusion in diff-mode might do it.
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.
I have tried emacs on and off for a while now and every time I start emacs, I go through the same routine. Customizing. The first one is binding return to newline-and-indent. (g)Vim does this by default. Showing matching parenthesis is also done by default on (g)Vim. It is grea that I can customize emacs to my heart's content but why doesn't emacs have nice and easy defaults? For reference, I am now using Emacs 23 on a RHEL5 box.
Probably because RMS didn't want it, that and because changing long-standing defaults is just an issue of politics. Like vi, Emacs has a hard-core following and basic changes like these are minefields.
Note: if you saved your customizations, then you wouldn't have to re-do them every time...
To have those nice and easy defaults, install Emacs Starter Kit. It enables by default a bunch of useful and convenient features make even the advanced Emacs users more productive.
Otherwise, as TJ pointed out, Emacs Customization Mode (type M-x customize) allows you to save permanently any of the settings. You can even store them in a separate file from your dotemacs―(setq custom-file "~/.emacs-custom.el")―so you can use it in every computer you work on.
The title of your question doesn't really reflect what your question is (and has been answered by Trey and Torok), but I'll tell you why I like it being bound to just newline: useless whitespace. Say you are nested inside a conditional in a function etc. and hit return a couple times to leave a blank line. The blank line now has a bunch of space chars on it. Yes, you can (and I do) remove trailing whitespace before saving, but I also have visual whitespace mode on and I can see it there taunting me.
Emacs reindents the current line whenever I type certain things, like ";" or "//". This is pretty annoying, since there are a whole lot of places where it isn't smart enough to indent correctly.
How do I disable this feature? I still want to be able to indent the line with TAB, but I don't want any source code I type to cause it to reindent.
(I'm using Dylan Moonfire's C# mode, but this probably applies to any cc-mode.)
Try running c-toggle-electric-state to turn off the electric action of these characters.
You can do this as part of a c-mode-common-hook, or toggle the state manually by hitting C-c C-l.
most likely caused by the inline-and-indent 'feature' of c-mode and derivatives. emacswiki has several solutions.