I'm using auto-complete-mode which I think is totally fantastic. I'm also a big fan of linum-mode but I've got a very irritating issue when the two are used together, especially when I'm working in a new buffer (or a buffer with very few lines).
Basically the buffer is 'x' lines long but when auto-complete kicks in it "adds" lines to the buffer, so linum-mode keeps switching, for example, between displaying line numbers on one column or two columns, depending on whether auto-complete is suggesting a completion or not.
So you type a sentence and you see your buffer's content frantically shifting from left to right at every keypress. It is really annoying.
I take it the solution involves configuring the linum-format variable but I don't know how.
Ideally it would be great if my linum-format was:
dynamic
right-aligned
considering there are 'y' more lines to the buffer than what the buffer actually has
My rationale being that auto-complete shall not suggest more than 'y' suggestion and that, hence, the two shall start playing nicely together.
For example, if 'y' is set to 20 and my buffer has 75 lines, then linum should use two columns: because no matter where I am auto-complete shall not make the buffer 'bigger' than 99 lines.
On the contrary, if 'y' is still set to 20 and my buffer has 95 lines, then linum should use three columns because otherwise if I'm near the end of the buffer and auto-complete kicks in my buffer shall start "wobbling" left and right when I type.
I'd rather not hardcode "3 columns wide" for linum.
I guess using "dynamic but always at least two columns" would somehow fix most annoyances but still something as I described would be great.
P.S: I realize that my 'fix' would imply that linum would always display on at least two columns, and I'm fine with that... As long as it stays right-aligned and use 2, 3 or 4 columns depending on the need.
Simply put the following line in .emacs which resolves this issue. It is in auto-complete.el.
(ac-linum-workaround)
I've written a couple of previous answers on modifying the linum-mode output, which you could probably adapt to your purposes.
Relative Line Numbers In Emacs
Colorize current line number
Edit: Here's the most basic version of that code (also on EmacsWiki, albeit somewhat buried), which doesn't modify the default output at all, but uses the techniques from those other answers to be more efficient than the default code. That's probably a more useful starting point for you.
(defvar my-linum-format-string "%4d")
(add-hook 'linum-before-numbering-hook 'my-linum-get-format-string)
(defun my-linum-get-format-string ()
(let* ((width (length (number-to-string
(count-lines (point-min) (point-max)))))
(format (concat "%" (number-to-string width) "d")))
(setq my-linum-format-string format)))
(setq linum-format 'my-linum-format)
(defun my-linum-format (line-number)
(propertize (format my-linum-format-string line-number) 'face 'linum))
Just have the same problem, after seeing 'patching the source' I believe it could be done with advice. Here is what I come up with
(defadvice linum-update
(around tung/suppress-linum-update-when-popup activate)
(unless (ac-menu-live-p)
ad-do-it))
I would like to use popup-live-p as mentioned but unfortunately it requires the variable for the popup, which we couldn't know in advance.
Update:
I ended up patching the source for linum.el. I added an extra hook that runs before updates.
Here's the patched file: linum.el (github)
Here's the code I have in my init.el:
;; Load custom linum.
(load-file "~/.emacs.d/linum.el")
;; Suppress line number updates while auto-complete window
;; is displayed.
(add-hook 'linum-before-update-hook
'(lambda ()
(when auto-complete-mode
(if (ac-menu-live-p)
(setq linum-suppress-updates t)
(setq linum-suppress-updates nil)))))
Hope it helps!
Related
I use emacs for my creative writing. To better analyze the structure of my sentences I would like to see my paragraphs displayed as consisting of one sentence per line. So I need a function that can take a normal auto-filled paragraph and do the following: 1) stretches all sentences into one line, and 2) put only one sentence per line.
Imagine I had written the following paragraph (lyrics from Suzanne Vega)
My name is Luka. I live on the second floor. I live upstairs from you. Yes I think you've seen me before. If you hear something late at night. Some kind of trouble. Some kind of fight.
With the function I want the paragraph would appear like this:
My name is Luka.
I live on the second floor.
I live upstairs from you.
Yes I think you've seen me before.
If you hear something late at night.
Some kind of trouble.
Some kind of fight.
Since I would like to do some of the writing when the sentences are displayed like this, the function should in addition to stretching out the sentences also turn off the autofill mode.
Ideally I would like a function that can toggle the display between auto-fill mode with all sentences wrapped, and this new mode with auto-fill turned off and all sentences stretched out.
Thanks in advance to all sort of suggestions or help to make such a function!
#Drew: Here is a text I am not able to split up with your code:
There are two ways to enable it: the first is with M-x visual-line-mode (for those with real menus, apparently Options->Line Wrapping in this Buffer->Word Wrap), which will give you a minor mode “wrap” in the mode line. As explained in C-h f visual-line-mode, one of the effects of this command is to subtly change the effect of commands that deal with “lines”: C-a, C-e no longer go to the end of the line (as in \n), but go to the end of the line (as in display line). M-a, M-e still work as they should. In addition, vertical split windows are guaranteed to not be truncated, and resize properly on changing width. Works wonderfully, especially if you have free form text that you’re keeping in version control (like a thesis in Latex) where hard-wrapping just doesn’t work out very well. It also makes vertical splitting much more useful, especially with huge windows. In my experience, it slows down redraw a little bit, but it’s worth it.
I guess something like this is what you're asking for.
(defun split-para-at-sentence-ends ()
"Split current paragraph into lines with one sentence each.
Then turn off `auto-fill-mode'."
(interactive)
(let ((mode major-mode))
(unwind-protect
(progn (text-mode)
(save-excursion
(let ((emacs-lisp-docstring-fill-column t)
(fill-column (point-max)))
(fill-paragraph))
(let ((bop (copy-marker (progn (backward-paragraph) (point))))
(eop (copy-marker (progn (forward-paragraph) (point)))))
(goto-char bop)
(while (< (point) eop)
(forward-sentence)
(forward-whitespace 1)
(unless (>= (point) eop)
(delete-horizontal-space)
(insert "\n"))))))
(funcall mode)))
(auto-fill-mode -1))
(define-minor-mode split-para-mode
"Toggle between a filled paragraph and one split into sentences."
nil nil nil
(if (not split-para-mode)
(split-para-at-sentence-ends)
(auto-fill-mode 1)
(fill-paragraph)))
(global-set-key "\C-o" 'split-para-mode) ; Or some other key.
this is my first question, so apologies for breaking any rules.
I've just started writing some functions in elisp to help me navigate certain types of text files more efficiently. To make these accessible, I've added some buttons to the tool-bar. As it's now becoming busy, I'd like to either: 1) move some of these additional buttons to a second line; or 2) instantiate a second tool-bar that could be placed somewhere else in the frame (either under the existing tool-bar, or perhaps vertically along the side where the scrollbar is).
I've searched high and low but am unable to find an existing example of this and, as I don't yet really know what I'm doing, I wonder if somebody has a code snippet from which I might start to hack a solution together.
Many thanks in advance.
System: CentOS 5/6, emacs for linux 23.1
Edit:
Thanks for the comment, William. Here's a simple example representing what my tool-bar code might do:
;
; functions used by the toolbar
;
;
(defun copy-paste-whole-line ()
"copies and pastes the whole of the current into a new line underneath"
(interactive)
(beginning-of-line)
(set-mark (point))
(end-of-line)
(setq temp (buffer-substring (region-beginning) (region-end)))
(message " copying: %s" temp )
(newline)
(insert temp))
;
;
; population of the toolbar:
;
;
(when (find-image '((:type xpm :file "copy_paste_line.xpm")))
(unless tool-bar-mode (tool-bar-mode 1))
; (setq tool-bar-map (make-sparse-keymap)) ; <- uncomment this line to have only this button present
(tool-bar-add-item
"copy_paste_line"
'copy-paste-whole-line
'copy-paste-whole-line
:help "copies and pastes the whole of the current line into a new line underneath"))
so, as you can see (actually, I'm not allowed to post images until I have 10 reputation points, so you won't be able to see), the code adds an extra button to the end of the existing tool-bar buttons. I believe this to be a reasonable way to achieve this, but I'm not an experienced elisp programmer, so if you think it's poorly written, please comment - I'd like to understand why... :)
If I only had 1 button, it would be ok like that, however, I have multiple buttons. I would, thus, like to add them to a second instance of a similar tool-bar (or, perhaps a vertical one placed where the scrollbars are).
Thanks again for any input.
Frame parameter tool-bar-lines is supposed to control this. You can, for instance, customize option default-frames-alist if you want to change the number of tool-bar rows to 2 or 3 everywhere. Or you can do this on a mode-by-mode or frame-by-frame basis. You can, for instance, use M-: (set-frame-parameter nil 'tool-bar-lines 3).
Depending on your platform (and toolkit), the behavior might be variable. See the Elisp manual, node Layout Parameters and node Tool Bars.
I believe you are out of luck. It seems to me that (at least on ubuntu and cygwin) only one row of buttons in the tool-bar is supported.
Here is what I have tried without luck on both systems:
(progn
(set-frame-parameter nil 'tool-bar-lines 3)
(loop for i from 1 upto 20 do
(setcdr tool-bar-map (cons (cadr tool-bar-map) (cdr tool-bar-map)))))
The following picture shows what I get:
The other buttons appear in a pull-down menu if you click on the little triangle at the right end of the toolbar:
You can restore the old tool-bar with the following commands:
(progn
(setq tool-bar-map (make-sparse-keymap))
(tool-bar-setup))
Finally, I have 3 rows of buttons. This is possible with emacs-w32:
So it is the gtk+ / nextstep problem.
I get this graphical error with linum-mode in my Emacs. I tried upgrading from 23 to 24 (via git) and I've tried both with various supplied binaries online and with my home-compiled version. What I'm really interested in is where to start diagnosing the problem.
The problem goes away if I scroll the torn line numbers off screen and back in.
I have experienced the same problem and spent quite some time trying to resolve it. The graphical error is a result of a clash between linum-mode and how the fringe is rendered. Unfortunately, I was unable to resolve the problem in linum.el, and the fringe display code is part of the C-source.
It can still be done! The easiest way to fix it is to just turn off the fringe.
M-x fringe-mode RET none RET
To make the fringe permanently stay off, I recommend customizing the settings with M-x customize-group RET fringe because some compiled versions of Emacs for Mac OS X have their own fringe settings that can override parts of your .emacs file.
I don't really need those line wrap indicators, so not having a fringe doesn't bother me. However, I did miss a slight separation between the line numbers and the buffer text. I followed the advice of a post on the Emacs Wiki to get that spacing back. In version 0.9x of linum, change line 160 from
(setq width (max width (length str)))
to
(setq width (max width (+ (length str) 1)))
The inspiration for this change is here: http://www.emacswiki.org/emacs/LineNumbers
There are arguments at the source link to set the linum-format variable instead of modifying linum.el. While I understand where they are coming from, most color-themes these days would color the extra space and not provide what I am looking for (a separation of about a space that is the background color). If you do edit linum.el, make sure to run
M-x emacs-lisp-byte-compile-and-load
to make the changes persistent. You can see the result of this by looking at the space before the cursor in the picture found here: http://i.stack.imgur.com/TxyMr.png (I don't have enough reputation to embed images).
No more graphical artifacts!
I had the same problem and I figured out a solution and while it's not the prettiest, due to an extra space to the left of the line number, it's much more elegant than changing the linum.el. Here is the pertinent part of my ~/.emacs:
;; Linum mode
(global-linum-mode t)
;; Offset the number by two spaces to work around some weird fringe glitch
(setq linum-format " %d ")
This removes the fringe overlay issue and does not have any other impact other than offsetting the line number.
to make a separation between the line numbers and the buffer text, the follow change will be better:
In version 0.9x of linum, change line 150 from
(concat "%" (number-to-string w) "d")))))
to
(concat "%" (number-to-string w) "d ")))))
This make the separation have the same background color with line numbers'.
This is how I have it setup in my .emacs and I don't have the problem, although I also don't use emacs with gtk or any other gui.
(linum-mode +1)
(setq linum-format "%d ")
You might want to hack around with (setq linum-format) to see if you can get good results. Also don't forget to browse emacswiki on linum.
The problem was still here on emacs 24.4, OS X 10.10.1.
The solution I worked out:
after loading the theme of your choice:
(load-theme 'whatever)
(set-face-attribute 'fringe nil :background (face-background 'default))
This question is related to another one, Emacs :TODO indicator at left side. I recently came across a minor mode I like a lot called FixmeMode. It supports auto highlighting of TODO marks, and navigating between them. However, I think it makes more sense to recognize the "TODO" strings only in comments, rather than polluting the whole file. Is it possible?
Check out the library fic-mode.el, it has been verified in C++ and Emacs-Lisp.
It was written specifically to answer this question.
The installation is like any standard package:
(require 'fic-mode)
(add-hook 'c++-mode-hook 'turn-on-fic-mode)
Though Wei Hu did ask for an easy way to add it to multiple modes, so here goes:
(defun add-something-to-mode-hooks (mode-list something)
"helper function to add a callback to multiple hooks"
(dolist (mode mode-list)
(add-hook (intern (concat (symbol-name mode) "-mode-hook")) something)))
(add-something-to-mode-hooks '(c++ tcl emacs-lisp) 'turn-on-fic-mode)
It's possible but quite a bit trickier. Fixme mode uses font-lock to do its highlighting, so it works on an as-you-type basis to highlight the keywords. Font-lock hooks in at a very low level, basically running after every change is made to the buffer's contents. It is highly optimized, though, which allows it to appear instantaneous on modern computers.
The TODO indicator in the left fringe is static. Execute the function and all current TODO's are highlighted; change the buffer (adding or removing TODO's) does not change the fringe indicator; that's only changed when the function runs again.
Your approach would have to get into syntax tables, determining first when you're in a comment and then looking for the keywords. The tricky part comes in doing this interactively (i.e. as you type). You should be able to hook into the font-lock constructs to do this, but the function you provide to search for the comment syntax table and then for the keywords better be very efficient, as it will be run each and every time a buffer changes (though it will only run on the changed region, I think). You would want to stuff all of this in font-lock-syntactic-keywords rather than font-lock-keywords because the syntactic-keyword pass happens before the syntactic pass (which happens before the keyword pass), and you need to set TODO inside comments before comments themselves are set.
Sorry it's not a full working-code answer.....
Maybe this will help: there's a fn c-in-literal in
cc-mode, and a similar csharp-in-literal in csharp mode. The
return value is c if in a C-style comment, c++ if in a C++
style comment. You could add that to the code at
Emacs :TODO indicator at left side
to get what you want.
(defun annotate-todo ()
"put fringe marker on TODO: lines in the curent buffer"
(interactive)
(let (lit)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "TODO:" nil t)
(progn
(setq lit (c-in-literal)) ;; or csharp-in-literal
(if (or (eq lit 'c) (eq lit 'c++))
(let ((overlay (make-overlay (- (point) 5) (point))))
(overlay-put overlay 'before-string
(propertize "A"
'display
'(left-fringe ;; right
horizontal-bar
better-fringes-important-bitmap))))))))))
https://github.com/tarsius/hl-todo seems to do exactly what you want. I just tried it and love it.
Building on Getting Emacs to untabify when saving certain file types (and only those file types) , I'd like to run a hook to untabify my C++ files when I start modifying the buffer. I tried adding hooks to untabify the buffer on load, but then it untabifies all my writable files that are autoloaded when emacs starts.
(For those that wonder why I'm doing this, it's because where I work enforces the use of tabs in files, which I'm happy to comply with. The problem is that I mark up my files to tell me when lines are too long, but the regexp matches the number of characters in the line, not how much space the line takes up. 4 tabs in a line can push it far over my 132 character limit, but the line won't be marked appropriately. Thus, I need a way to tabify and untabify automatically.)
Take a look at the variable "before-change-functions".
Perhaps something along this line (warning: code not tested):
(add-hook 'before-change-functions
(lambda (&rest args)
(if (not (buffer-modified-p))
(untabify (point-min) (point-max)))))
Here is what I added to my emacs file to untabify on load:
(defun untabify-buffer ()
"Untabify current buffer"
(interactive)
(untabify (point-min) (point-max)))
(defun untabify-hook ()
(untabify-buffer))
; Add the untabify hook to any modes you want untabified on load
(add-hook 'nxml-mode-hook 'untabify-hook)
This answer is tangential, but may be of use.
The package wide-column.el link text changes the cursor color when the cursor is past a given column - and actually the cursor colors can vary depending on the settings. This sounds like a less intrusive a solution than your regular expression code, but it may not suit your needs.
And a different, tangential answer.
You mentioned that your regexp wasn't good enough to tell when the 132 character limit was met. Perhaps a better regexp...
This regexp will match a line when it has more than 132 characters, assuming a tabs width is 4. (I think I got the math right)
"^\\(?: \\|[^ \n]\\{4\\}\\)\\{33\\}\\(.+\\)$"
The last parenthesized expression is the set of characters that are over the limit. The first parenthesized expression is shy.