I have an extensive emacs configuration. Unfortunately, auto-fill-mode is broken within LaTeX-mode for some reason. How can I debug this without binary searching my emacs configuration for the error?
Alternatively, how can I make this function not set an undo point? It's annoying to have to press undo once per word and space in the document.
(local-set-key (kbd "SPC")
(lambda () (interactive) (fill-paragraph)
(insert " ")))
Well, you can try M-x debug-on-entry auto-fill-mode.
But my advice would be to use do the binary search you're trying avoid. There is nothing faster. My init setup is probably at least as extensive as yours, and I sometimes think there is a quicker way to guess what the problem is, and time and again I've been taught the lesson that binary search is the way to go. It just seems slow and silly at first.
Remember the parable of the wise man who convinced a ruler to pay him with one grain rice on the first chessboard square, 2 on the second square, 4 on the third, and so on. It really doesn't get any better than binary search when you have no idea where the problem is, and even often when you think you can guess the general location of the problem. Just do it.
Related
I'm considering switching back from flycheck to flymake after the Emacs 26 rewrite. One thing that bothers me about flymake is how much room on the mode line it takes up. It has a string Flymake plus the results. It seems like a silly thing but this is 10% of the mode line on an 80-char frame, just for a name! I have lots of important info I'd like to see on my mode line so I try to remove things that aren't helpful to me--I know what minor modes etc. are enabled in my buffers, since I configured them! Personally I'd prefer to not see a name at all, just the results, or at most F or FM.
I could use diminish to get rid of the mode line info completely but of course I don't want that: I want to be able to see the state of my buffer.
I took a look at flymake.el and the flymake--mode-line-format defun and it doesn't seem like this string is configurable, or easy to change at all.
Anyone have any thoughts about this?
You'd need to redefine flymake--mode-line-format function. It should probably be more customizable, but it's not. Possibly the least intrusive way to do it is to define :filter-return advice on that function to transform the output.
(defun flymake--transform-mode-line-format (ret)
"Change the output of `flymake--mode-line-format'."
(setf (seq-elt (car ret) 1) " FM")
ret)
(advice-add #'flymake--mode-line-format
:filter-return #'flymake--transform-mode-line-format)
I've been using Vim for a several years. And now I want to give a try to Emacs.
For Vim I have a general config file (here) where I'm overriding defaults (e.g. hey, Vim, show me the line numbers; save more history, don't create these stupid backup files, etc...)
I want the same thing for Emacs. While searching, the best thing I've found is better-defaults.el from technomancy. I'm still digging in Prelude and Emacs-Starter-Kit sources, but there are too many overrides and plugins.
So, what I want:
ability to see a list of variables, which I can customize (e.g. indent-tabs-mode or newline-and-indent). I know about C-h v variable-name but this command requires me to know a name of variable, but I want a list of them
sample config file for Emacs which sets helpful defaults with comments for each command
For your first question: M-x customize-option.
C-h v TAB is not what you want, as it shows you also non-option variables (e.g., internal variables).
However, if you load library help-fns+.el then C-u C-h v TAB shows you only the user options (in buffer *Completions*).
My advice would be to not look for an existing "sample config file", if you intend to start with it, as opposed to just seeing how another user redefines things. And for help with the latter, I would still recommend the Emacs manual over looking at someone elses init file. Especially to start with.
However, if you really want to look at init files from other users then this is the place to start. (And this is a good place to start, other than the manual (which is the best place), to learn about customizing Emacs.)
Finally, my (unsolicited) advice wrt learning Emacs, including customizing, is to start by not customizing it at all. I say that without irony as one who has heavily customized Emacs.
If you want to "get it", i.e., to get a feel for the Emacs design and what makes it different, then let yourself get used to Emacs as it is out of the box -- for maybe a month or so. At that point you can think about customizing, and your customizations are likely to be much wiser (in your own terms, i.e., for whatever it is that you want).
Another way of putting this is that until you know Emacs a bit, you really do not know what it is that you want or need in terms of customization. In particular, it would be a mistake, IMO, to start out by trying to think of Emacs in terms of Vim or trying to make Emacs do what you've done in Vim. There is plenty of time for that later, if, based on understanding Emacs, you really do want to do that.
Welcome to Emacs. Enjoy.
I'm going to take a reasonable dissent from Drew's excellent answer, there are some things you really ought to set in your emacs-file immediately, that aren't set out of the box that you really ought to set.
Issue number 1: THAT $(generate-swearing) BELL!
The bell will ding like a madman. That's annoying. You can turn it off.
In your init-file, do this:
(setq visible-bell 1)
Issue number 2: Emacs has an interesting view of backup files.
If you edit a file, say "foo.txt", emacs will create little backups of the file with the name "foo.txt~" in the same directory.
This is annoying as all hell, and you can fix it by doing this:
(setq backup-directory-alist '(("" . "~/.emacs.d/emacs-backup")))
Issue number 3: Emacs uses C-w differently than bash does, and that's a bit annoying.
C-w usually deletes a word backwards. By standard in emacs, it deletes the marked region. That's a bit silly.
It is better to do something like this:
;; This is my preference, your mileage may vary.
(global-set-key (kbd "C-x C-k") 'kill-region)
(global-set-key (kbd "C-x k") 'kill-buffer)
(global-set-key (kbd "C-w") 'backward-kill-word)
Issue number 4: Alt-X is a clunky way of running an interactive command.
It is better to do something like this instead, avoid your hand cramping up all the time.
(global-set-key (kbd "C-x C-m") 'execute-extended-command)
(global-set-key (kbd "C-x C-m") 'execute-extended-command)
You also may want to check out Steve Yegge's Effective Emacs: https://sites.google.com/site/steveyegge2/effective-emacs
It's pretty amazing. One thing to note though is that the caps-lock to ctrl thing is also available through a microsoft tool here:
https://learn.microsoft.com/en-us/sysinternals/downloads/ctrl2cap
This is better than the manual hack Yegge suggests, and you can turn it off if you don't like it.
In vanilla emacs, I load the TAGS file, and do a lookup of a symbol with "M-.". I go right to the definition of the symbol.
When using Icicles, I get 374 hits for the same symbol. While I can in theory chip away the non-elephant slowly to find what I want, that's a pain, and I end up just turning off icicles for the tag lookup, and turning it back on.
Is there any way to tell icicles that I just want the definition when I do a tags lookup, and not every relevant match in the tags file?
For instance, I might search for the definition of the task_struct structure in the linux kernel source code. I see many definitions of the form:
struct task_struct taskInfo;
struct task_struct info;
but all I want is the one definition:
struct task_struct {
While I can "chip away the non-elephant, the elephants are pretty similar here, and it is hard to tell while looking at the search results that I only want lines with a curly brace after the name, and the curly brace might have been on a different line anyhow, so there is no guarantee even that is the right way to slice the results.
I've also seen member functions of a class appearing when I use Icicles, and I'd like a way to turn them off more easily.
Tried reading the emacs wiki and an internet search, but I didn't have much luck just searching for "emacs icicles tags".
If vanilla M-. does what you want, doesn't icicle-find-first-tag' also do what you want? (Notice the-first'.)
http://www.emacswiki.org/emacs/Icicles_-_Emacs_Tags_Enhancements#icicle-find-first-tag
I don't use icicles, so I don't know if this will actually work, but give it a whirl and let me know.
(defadvice find-tag (around my-thawed-find-tag)
"Disable icicles when finding tags."
(let ((icy-state icy-mode))
(if (not (equal (icy-mode 0)))
(progn
(icy-mode 0)
ad-do-it
(icy-mode icy-state))
ad-do-it)))
(ad-activate 'find-tag)
The advice around find-tag wasn't really what I was looking for. Instead, what I need is a way to get the definition sometimes and references sometimes. I found that cscope and the xcscope.el plugin did what I needed (and CEDET also did something similar to solve my problem)
I recently added the line
(set-default-font "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1")
to my .emacs file. After that find-file-other-window always opens a new window instead of utilizing existing windows. Why would that happen!? How can I fix it?
I don't understand how all this font-config magic works, so if it's actually obvious I'm sorry.
Edit: I have a pretty large resolution, and my font size has decreased pretty significantly. Does find-file-other-window take into account available character space? Perhaps it's deciding there's sooo much room it can afford to just open windows willy nilly.
find-file-other-window ultimately calls display-buffer, which runs a complex algorithm to decide whether to reuse an existing window or make one and how. In particular, if display-buffer decides it needs to create or recycle a window, it tries calling split-window-preferred-function to split the biggest window. By default, split-window-preferred-function is split-window-sensibly, which is willing to split windows vertically if they are more than split-height-threshold lines high, or failing that horizontally if they are more than split-width-threshold columns wide.
It looks like you want
(setq split-width-threshold nil)
(setq split-height-threshold nil)
N.B. This answer applies to GNU Emacs 23. Earlier versions didn't have horizontal splitting. Later versions may do things differently.
A few ways to find this out (none straightforward):
If you guess that what's going on is called splitting a window: M-x apropos RET split RET shows a number of variables and functions, and you might figure out which ones are relevant. Or if you guess that there's an option (there often is), C-h v split- TAB shows promising leads.
The documentation for find-file-other-window references Displaying Buffers. (You have to go to the Elisp manual for this level of detail; within Emacs, C-h i m elisp RET brings up the Elisp manual, and i find-file-other-window RET leads you to the documentation for this function.) It's less clear that pop-to-buffer is the passage to read there; it references Choosing Window which contains the sought after information.
C-h f find-file-other-window RET shows the built-in documentation for the function. It links to display-buffer. The description of display-buffer doesn't describe its operation in detail, so from there you need to either consult the Elisp manual as above or explore the source of display-buffer by clicking on window.el.
I've recently started using ido-mode, which, overall, is pretty nice. But one thing seems especially broken, and I'm wondering if there's a setting (ha) buried in there to fix it.
ido-switch-buffer doesn't seem to care about buried buffers. That is, if I use bury-buffer, and then ido-switch-buffer, the first choice is often the one I just buried.
Is there an easy way around this? The whole point of burying a buffer is that I don't want to see it again any time soon.
Acording to the documentation (C-h f bury-buffer)
Put BUFFER-OR-NAME at the end of the list of all buffers.
There it is the least likely candidate for 'other-buffer' to return;
thus, the least likely buffer for C-x b to select by
default.
So, if you use bury-buffer the buffer will be still available (at the end of the list), so it's normal that ido-switch-buffer find it.
If you don't want to see that buffer ever, you should think of closing it.
I can't reproduce this. On Emacs 23, as far as I can tell, ido-switch-buffer lists the buffers in the correct order.
In any case, you might try out iswitchb instead. It's kind of like ido, only older and more specific to buffer switching. If you like it, you can use iswitchb for buffer switching and ido for everything else.
can't reproduce this either: when i bury a buffer and call ido-switch-buffer afterwards, the buried buffer is NOT at the front of the switch list.
i have done quite a bit of ido customization (to get it working well with dired, etc), but my main ido settings are:
(setq ido-show-dot-for-dired t)
(setq ido-default-file-method 'samewindow)
(setq ido-default-buffer-method 'samewindow)
(setq ido-confirm-unique-completion t)
(setq ido-max-dir-file-cache 20)
my ido.el version is "1.57 released on gnu.emacs.sources adapted for emacs 22.1".
hth.
Use next-buffer or previous-buffer
FWIW, the default completion behavior of switch-to-buffer (C-x b) in Emacs-24 has been changed to use substring-match completion, so its behavior is similar to IDO while obeying the principle that "the default buffer shouldn't be the one I just buried". You can make it even more similar by turning on icomplete-mode (which does not change the completion behavior itself, but displays the completion candidates at the end of the minibuffer).