I'm inclined to like spacemacs, but I'm not a fan of Ido, and I find it pretty offputting to drop into ido-dired when I type C-x d. Is there a recommended way of preventing this?
In dotspacemacs/user-config I've added (ido-mode 0). It's a pretty blunt instrument, but it seems to be doing the trick. I'll keep poking; perhaps there's a nice way of preventing ido from being loaded in the first place.
Related
So I was wondering if there's a game out there that lets me practice my emacs cursor skills. I just started using emacs and thought that a game letting me control the player with the standard emacs bindings would be an awesome way to get going. When searching for one I stumbled upon this for VIM.
Does anyone know of something similar for emacs?
This is not a game, but I'd suggest installing hardcore-mode (available on Melpa too), and configure it to your liking (here's my configuration if interested). That package when enabled globally will force you to not use the arrow keys and use the C-f, C-b, C-n, C-p bindings instead. So much so that now using those bindings has become a second nature to me.
PS: There's an emacs-dedicated stackexchange site in case you didn't know.
One idea: Have a game mode that shows two buffers, and the goal is to transform the first into the second buffer with the least amount of keystrokes.
When using tools like Org-mode and Magit the mode will sometimes show help menus. For instance, org-mode export will show a nice menu that accept single keys and then executes some command. In Magit, when looking at the status view it will accept tabs to expand the staged and commit areas.
These areas, for both Git and Org, are nicely placed to take up some portion of the emacs frame that is mostly convenient. How does emacs do choose this?
Additionally, these views are read-only, up until the user presses tab in the case of Magit and the status view. Is there a best practice when creating these views which control editing, but allows the mode to edit the file and present alternative text?
Perhaps the answer is take a look at these function A, B, and C. Which is fine, I'm just learning and experimenting on my own.
Magit in particular is not the simplest introduction to popup buffers in Emacs, but it certainly is sophisticated and a good read. Find magit-popup.el on your machine, for example M-x find-function RET magit-popup-mode-setup. To me, that function looks like a good candidate to start reading that file. You can see the macro magit-define-popup in use for example in magit-push-popup in the file magit-remote.el
In the end, it boils down to opening a new buffer in a new window and give it a dedicated major mode which has all the key-bindings.
Another good candidate is the family of temp-buffer-* functions.
Hope, that gives some pointers to start reading.
An easy way to show menus/help screens à la Magit and org-mode is with Hydras:
http://wikemacs.org/wiki/Discoverability#Hydra
https://github.com/abo-abo/hydra/
https://github.com/abo-abo/hydra/wiki
It's a short elisp method to write and it will give you a menu like org-mode. For example:
(defhydra hydra-zoom (global-map "<f2>")
"zoom"
("g" text-scale-increase "in")
("l" text-scale-decrease "out"))
ps: it's not what org-mode and magit use. Magit's system wasn't re-usable until recently and I don't know how it compares with Hydra. A nice feature of Hydras is that you can tell it to not disappear after a keypress, so than you can press many keys in a row.
Sometimes Emacs stops to respond to key bindings, for example:
it's impossible to C-x C-s save buffer
it's impossible to C y yank killed text
when mark activated it's invisible
and many other disadvantages.
The only way to return normal behaviour is to relaunch Emacs, though such odd behaviour can occur again very soon. Also, switching buffer to and fro could help a bit, at least it is possible to write buffer.
What is possible reason of this breakage?
Remark: Please review. I've tried to simplify question, but if this still is not good enough, let me know and I'll delete it.
In my particular case the issue was introduced by conflict between git-gutter-fringe plugin and FlyCheck when both of them try to place fringe marks at the same place. To spot this kind of conflicts it is helpful to open * Messages * buffer (by default C-h e), where all kind of errors logged
To resolve problem, I simply rejected git-gutter-fringe plugin.
Hope, this will be helpful for somebody.
I spend a lot of my time in emacs, and for the most part it's wonderful. But one thing really drives me nuts when I'm deep in it, and that's control over which window various new buffers are opened in. When I do find-file, it always opens in the current window, and this is what I like. But tons of other modes like to split my windows for me, change the layout, and do various other things that annoy me. For example running M-x manual-entry seems to have no rhyme or reason about where it opens the manpage, and various org-mode commands do the same thing, closing windows I want to keep open, etc. I don't like having to redo my layout everytime I want to look at my org agenda or open a manpage.
In short, is there anyway to globally control which windows are used for modes that want to open in a window other than the current one? Can I direct them more easily? Or will I have to hack each mode to act the way I want it to?
Try Winner mode:
http://www.emacswiki.org/emacs/WinnerMode
It provides an undo/redo for changes to the window configuration.
This question has always bugged me too. I found this:
http://www.gnu.org/software/emacs/elisp/html_node/Choosing-Window.html
It looks like you can use (setf pop-up-frames t) to make stuff show up in a new frame.
Also, it looks like you can use display-buffer-function to override the display function (how buffers are chosen.) Of course, you'd have to be good at elisp.
I'm pretty old school sometimes and I like working with Emacs in my terminal. (I work with IDEs all the time. But sometimes, when in the privacy of my own home, I just like a text editor a terminal and a beer)
However, the default Emacs that comes with OS X does not seem to highlight the comments in font-lock-mode. I've seen this behavior in both Python and C mode.
I've already searched some forums and I found one post where the person was having the same problem as me:
http://forums.macosxhints.com/showthread.php?p=512361
Is is there any way to fix this problem?
I had this exact same problem. The solution is to change the color used for the comment face as follows:
(set-face-foreground 'font-lock-comment-face "red")
Or, if you only want to do this for certain modes:
;;; Only do this for the common C mode (C, C++, Objective-C)
(add-hook 'c-mode-common-hook #'(lambda () (set-face-foreground 'font-lock-comment-face "red")))
For more information on faces, see http://www.gnu.org/software/emacs/manual/html_node/emacs/Faces.html.
I'm not sure exactly how to fix it, but I'm fairly certain there's something you can put in the .emacs file. In fact, I think I've done that before. I'll look for my file and let you know what I can find.
I'll try and get you my .emacs file when I get home from work tonight.
[edit] I've looked and looked, and can't find a .emacs file on either system that I use, and on my OS X install (Leopard default), it looks like it does it correctly by default. I did some research here, and it looks like the default installations no longer use .emacs files, because there's folks like me that mess around with them and break things, and they got tired of having to help us fix it. But, there is a set of menus that will let you tweak things. Start by typing "M-x customize RET", where M is the meta character (on my OSX install, this is the esc key. Don't hold it down, just type it like a regular character. That'll get you into a menu of stuff you can change. I didn't poke around too much, so I'm not sure where in the menu you'll find what you're looking for. Sorry I couldn't be more help.
In my experience this is usually related to a unpaired quote (single-, double-, or otherwise) somewhere in an existing comment.
Hunt those occurences down and eradicate them in your source code (or if you are more ambitious, see if you can update the fontlock code in your major modes' emacs source code)
When I have encountered this in editting Perl in emacs, I often switch major modes to cperl-mode as it typically handles parsing the perl better than the default perl-mode.