global-auto-revert-mode sometimes doesn't revert my buffers. These are regular files (source code), and this happens most often when messing around in source control (e.g. stashing changes, rolling back to an earlier version, the updating and un-stashing).
Edit: After further investigation, emacs v. 24.5 is using libgio to get notifications of file changes, but some notifications are getting dropped: file-notify-callback isn't called for some of my files. Perhaps a buffer somewhere is overflowing when so many files are changed at once?
Related
I noticed that the VSCode editor sometimes mark/track changes (https://imgur.com/a/u4U2tdc where there's a blue mark next to line 16 to indicate a change) and sometimes it doesn't, and today it's not tracking changes for some reasons, and I am not sure what's causing the issue.
Could someone advise how to debug this issue?
This is controlled by the setting scm.diffDecorations. By default, it should be set to all:
Check this setting. Additionally, new files that you just added can't show these differences, because it (Git) has nothing to compare it to yet. The same can be said for untracked files.
Since I upgraded magit, executing magit-status replaces my patiently crafted window arrangement with a single, huge window. Ok, when quit magit it restores the frame layout. However, I never quit magit. I much prefer the old behavior, where magit-status stayed in the windows in which I ran it. Can I get the old behavior back?
There was no such change it Magit itself.
Are you using some "starter kit"? If so you should probably check there first.
(Emacs newbie here)
Sometimes a Help buffer gets opened in my emacs editor. It opens in a different pane, splitting the current window into two halves vertically.
When I use C-k buffer-name, to kill a buffer (say Help), some other buffer (say scratch) gets opened automatically in that pane.
Is it possible to revert to my previous configuration, after a random buffer (Help or Debug..) gets opened.
My previous configuration would be to go back to a single window with no panes
To revert to the previous window configuration after any arbitrary change(s), you should enable winner-mode in your .emacs file:
(winner-mode 1)
Then you can use C-c<left> (repeatedly, if necessary) to undo window configuration changes with winner-undo.
C-c<right> calls winner-redo which returns you to the most recent configuration (immediately; not in single steps the like the 'undo' command).
Winner mode is the key to never ever getting annoyed by Emacs creating an unwanted window, but it also lets you do things you wouldn't have done before (for instance C-x1 to maximise one of your windows temporarily for easier reading, because getting back all the windows you just deleted is now trivial).
Obviously this is also incredibly useful if you accidentally mess up your window config!
Hello to revert back to one buffer you must hit C-x1 while standing in the buffer you want to keep. And to switch between frames C-xo
I have two windows open in my Emacs session. Both are remote files opened using tramp. I make a change in window A and switch to window B without saving file in window A. When Emacs decides to autosave, the buffer displayed in window B is switched to the buffer from window A that was autosaved. This only happens when using tramp, not local files.
Another thing I have noticed is, that if I have the same file opened in two windows, because I need to reference something at another position in the file and save the file, the buffer I'm in sometimes jumps to the position that the point is in the other window, so I have to move around to get back to the place where I was editing.
Is this a bug or is there some setting that I have(n't) set? I suspect it is something related to refreshing the windows when saving.
i'm using Emacs 24.3 on OSX, but I have seen this using Linux too.
Sounds very much like a bug, to me. Can you reproduce this starting from emacs -Q (i.e., with no init file)?
If so, use M-x report-emacs-bug to give Emacs Dev the recipe. If not, bisect your init file recursively until you locate the culprit code. Then ask for more help here, if it's not clear how to fix the problem.
(load "~/.elisp/nxhtml/autostart.el")
(setq mumamo-chunk-coloring 'no-chunks-colored)
I currently have the above in my .emacs and the chunk coloring is still showing up. I have also tried disabling it through customize-option and then setting the state to "no chunk coloring" in mumamo-chunk-coloring. I'm using the latest emacs23 from cvs and have the most recent nxhtml release.
What is the correct way to disable the coloring of different major modes?
Bug. I forgot to add this possibility back when implementing chunks in chunks.
I have just corrected this in 1.88 (which is yet in beta).
Note that in the new version you will use a number for mumamo-chunk-coloring. Set this to 1 to avoid coloring main mode chunks etc.
BTW: Just happened to see this. If you want bugs to be corrected it is normally much better to report them in nXhtml bug database on Launchpad.