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)
Related
I would like to invoke M-x helm-swoop such that it does NOT return the symbol at point. I find that it always picks up undesired symbols, e.g. when I invoke M-x helm-swoop in org-mode, I get Swoop: \*, and I then have to delete the \* before I can enter my desired search term. How can I do this?
This has been bugging me as well, for exactly the same reason (swoop in an Org-mode buffer picking up heading characters), so this question motivated me to go and look.
Looking at the source, Helm-swoop calls helm-swoop-pre-input-function to populate the prompt, and by default this is set to a function that returns (thing-at-point 'symbol), which is what causes the problem in headings.
A quick test with the following in my init file seems to work:
(setq helm-swoop-pre-input-function
(lambda () nil))
This could certainly be improved by, for example, keeping the default behaviour in non-Org buffers but as I'm only really using swoop in Org buffers this is good enough for me.
I personally keep all lines under 80 characters, but I also work on projects in teams where other programmers don't care about line length.
I love using whitespace-mode, but the long line visualization is really annoying when I'm working on projects where I shouldn't interfere with the long lines. It seems like it should be easy to turn off the long line visualization---I hit m-x global-whitespace-toggle-options l, and then can hit m-x global-whitespace-toggel-options ? to confirm that the "long-line visualization" is turned off. But long lines are still highlighted. I kill buffers and reload them, and highlighting is still there. I'm definitely using global, not local, whitespace-mode.
Why can't I turn off the long line visualization?
The last time I customized whitespace-mode, I noticed that my changes to the settings didn't have any effect in buffers that already existed; try recreating the buffer, or leaving and reentering whitespace-mode. In case you don't already know, you can use M-x customize-group whitespace to turn off that particular option entirely, rather than doing it manually.
Edit: Specifically you want to customize the whitespace-style variable. This lets you turn on and off individual styles. In this case you should turn off the ones labelled "(Face) Lines" and "(Face) Lines, only overlong part". The former changes the face of the whole line when it is overly long, while the latter only changes the face of the part that extends past the threshold.
(Other options in this group define the faces that whitespace-mode will use to highlight the styles you've turned on, the regexes it uses to identify certain situations, etc, but usually you only care about whitespace-style).
Set whitespace-line-column to a higher value (default is 80), so the highlighting of long lines doesn't kick in:
(setq whitespace-line-column 250)
I'm assuming that you already have whitespace-mode activated somewhere in your init.el or similar. If so, you can adapt duma's comment above, and either
Edit the elisp that sets whitespace-style to remove lines-tail. E.g., Emacs Prelude sets
(setq whitespace-style '(face tabs empty trailing lines-tail))
Simply change that to
(setq whitespace-style '(face tabs empty trailing))
If you don't want to directly edit that elisp, but rather override it later with your own code, do something like
(setq whitespace-style (delete 'lines-tail whitespace-style))
Unfortunately, if running Prelude with auto-loaded buffers (using something like Emacs Desktop), the initial setting will take precedence: for each buffer on which you want to see whitespace-style displayed as directed, you must [1]
kill the buffer
re-open the buffer
[1]: Note to OP: if there's another way to reload a buffer, please edit or comment this answer. I was hoping to find something like M-x reload-buffer but am not seeing anything like that with C-h a buffer.
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.
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'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).