I have a reverse problem of the usual issue of highlighting lines greater than 80 characters. I need to highlight lines that are LESS than 80 characters. I have googled but could not find any solution. I am ok with running a command and getting a dump of hte line numbers with less than 80 characters also. Inputs appreciated
Thanks
You can use highlight-regexp for this
M-x highlight-regexpenter^.\\{1,80\\}$enterenter
then use unhighlight-regexp to undo it. The one you entered will be in the history.
You could wrap this up in your own minor mode like this:
(define-minor-mode highlight-less-than-80-mode
"Minor mode for highlighting lines less than 80 characters."
:init-value nil
:global nil
:lighter "<80"
(if highlight-less-than-80-mode
(highlight-regexp "^.\\{1,80\\}$" 'error)
(unhighlight-regexp "^.\\{1,80\\}$")))
Also
I wrote column-enforce-mode to highlight lines longer than 80 columns, and I was able make it work the opposite way by only changing one unless to if and one (point) to (point-at-bol). If you'd like you could also install column-enforce-mode from melpa and make the modifications yourself. As of 8/25/2014 the two changes need to be made on lines 200 and 202. The difference with column-enforce-mode and using highlight regexp is that it measures columns, not characters, so that may or may not be what your are looking for.
This function will dump (as a list) the line numbers of lines shorter than 80 characters:
(defun id-short-lines (&optional nchars)
"Returns a list of lines less than NCHARS characters
long (default: 80)."
(let (lines)
(save-excursion
(goto-char (point-min))
(while (not (eobp))
(when (< (- (point-at-eol) (point-at-bol))
(or nchars 80))
(push (line-number-at-pos) lines))
(forward-line 1))
(nreverse lines))))
If this is a one-off problem (or at least a rare one), then the line dump is probably fine; otherwise, you might want to investigate the fill-column-indicator and faces as the comments suggest.
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.
I'd like to display a few lines at the top of the buffer, but not as part of the actual buffer text, just for display.
Specifically, I'd like to display a Git timeline (not yet released, sorry), like this automatically when I open a file, so I can easily see any recent activity:
P DP D D
T=F=S=S=M=T=W=T=F=S=S=M=T=W=T=F=S=S=M==T==W==T==F==S==S==M==T==W==T==F==S==S==M=
11 18 25 2 9
(Single chars are first initials of people with commits on those days. There will be a legend below as well)
It sounds like I want something like the header line, but for the buffer. Is there anything like that?
One idea I had was to use an overlay at the start of the buffer and put my text there, but I'm not at all sure this is "the right thing" or a completely inappropriate / unsuitable use of this.
I tried, and got it working, using an overlay of the char at (point-min), with the text-property of 'before-string and the string literal above (with newlines and a trailing newline). Here's a proof of concept:
(defun test/add-overlay ()
(interactive)
(setq test/timeline-overlay (make-overlay (point-min) (+ (point-min) 1)))
(overlay-put test/timeline-overlay 'timeline-panel t)
(overlay-put test/timeline-overlay 'before-string
(propertize " P DP D D \nT=F=S=S=M=T=W=T=F=S=S=M=T=W=T=F=S=S=M==T==W==T==F==S==S==M==T==W==T==F==S==S==M=\n 11 18 25 2 9
" 'face 'font-lock-comment-face))
)
(defun test/remove-overlay ()
(interactive)
(remove-overlays (point-min) (point-max) 'timeline-panel t)
)
This does seem to work quite fine, but I'm not sure if it might conflict with something else.
Is this the way to go, or are the more suitable user interface constructs in Emacs to do what I want?
If you can reduce it to a single line, then use header-line-format -- it's local in every buffer. Just set the variable for the buffer you want. See the Emacs sources for examples, e.g., ruler-mode.el.
You seem to have dismissed using a header line, saying that you want something "for the buffer". I don't understand why you think header-line-format does not give you what you want (except that it is one line only).
Yes, if you want display-only text placed at a particular location in the buffer, then an overlay with some after-string or before-string is the way to go.
Modes: I'm using linum for line numbers, the package linum-relative for relative line numbers. If it matters, I am also using visual-line-mode. These are flexible.
Currently, a single line (i.e. text without a newline) is numbered as only one line, regardless of how many times it is wrapped. I am wondering if there is a way to change the numbering to respect these wraps. So, for example,
263 This is all in
a single line
without newlines
might become:
263 This is all in
264 a single line
265 without newlines
and, in relative mode:
0 This is all in
a single line
without newlines
might become:
-1 This is all in
0 a single line
1 without newlines
I really only want the change in relative mode, but would not mind if it spills over into absolute mode.
A toggled change that works on both would be most useful - that way, the user can specifically select when, or with which modes, to turn it off or on.
If the goal is navigation, I suggest a similar solution via the popular ace-jump-mode.
If the goal is just persistent line numbering, you might consider longlines-mode instead of visual-line-mode (but I would avoid this, personally).
ace-jump # GitHub
https://github.com/winterTTr/ace-jump-mode
Demo:
http://dl.dropboxusercontent.com/u/3254819/AceJumpModeDemo/AceJumpDemo.htm
With it, you can jump to any line with as little as two keypresses.
In addition to lines, you can jump to the start of any word; there's also individual character-level jump precision. If desired, it can be configured to restrict jumps to the current window/buffer, or across all windows in the current frame, and even multi-frames.
It doesn't, however, recognize wrapped lines as jump-able locations. Again, you might consider longlines-mode as a fix for this if it is really important to you, but as I understand, it's considered hack'ish and deprecated in favor of visual-line-mode. Though, with longlines-mode, the lines are renumbered exactly as you want in your first example.
I'm assuming the goal is navigation, and as such, I think you'll find with just a little practice that word-based jumping or even jumping via incremental search to be a superior solution.
Update
Here's a simple solution to trick ace-jump to scan within N lines using emacs narrowing features; perhaps others can improve upon it. You could also do something similar for word and line modes.
(defun brian-ace-jump-to-char-within-N-lines (&optional n)
(interactive "p")
(let* ((N (or n 0))
(query-char (read-char "Query Char:"))
(start (save-excursion
(forward-line (- N))
(point)))
(stop (save-excursion
(forward-line (1+ N))
(point))))
(unwind-protect
(condition-case err
(progn
(narrow-to-region start stop)
(ace-jump-char-mode query-char))
(error
(message (error-message-string err))))
(widen))))
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!
I'm using GNU Emacs 23.3 on Windows. I work in a very large codebase for which I generate a TAGS file (using the etags binary supplied with Emacs). The TAGS file is quite large (usually hovers around 100MB). I rarely need to use any functionality beyond find-tag, but there are times when I wish I could do completion out of the TAGS table.
Calling complete-tag causes Emacs to make a completion table automatically. The process takes quite a bit of time, but my problem isn't in the amount of time it takes, but rather the fact that right at the end (around 100% completion), I get a stack overflow (sorry about the unprintable chars):
Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
re-search-forward("^\\(\\([^]+[^-a-zA-Z0-9_+*$:]+\\)?\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:]*\\)\\(\\([^\n]+\\)\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n" nil t)
etags-tags-completion-table()
byte-code(...)
tags-completion-table()
Has anyone else run into this? Know of a way to work around it?
EDIT: Stack output after turning on debug-on-error
EDIT: Removed stack, since I now know what the failing entries look like:
^L
c:\path\to\some\header.h,0
^L
c:\path\to\some\otherheader.h,0
My tags file contains quite a few entries in this format. Looking at the headers involved, it's clear that they couldn't be correctly parsed by etags. This is fine, but I'm surprised that tags-completion-table doesn't account for this format in its regex. For reference, here's what a real entry looks like:
^L
c:\path\to\some\validheader.h,115
class CSomeClass ^?12,345
bool SomeMethod(^?CSomeClass::SomeMethod^A67,890
The regexp in question is used to match a tag entry inside the TAGS file. I guess that the error can occur if the file is incorrectly formatted (e.g. using non-native line-endings), or if an entry simply is really, really large. (An entry is typically a line or two, which should not be a problem for the regexp matcher.)
One way of tracking down the problem is go to the TAGS buffer and see where the point (cursor) is, after the error has occurred. Once you know which function it is, and you could live without tags for it, you could simply avoid generating TAGS entries for it.
If the problem is due to too complex entry, I would suggest that you should send bug report to the Emacs team.
If you load the tags table (open the TAGS table with Emacs, then bury-buffer), try M-x dabbrev-expand (bound to M-/). If the present prefix is very common, you might end up running through many possible completions before reaching the desired one.
I don't use Windows, but on the Mac and Linux machines I use, I have not faced this issue.
This looks like a bug in Emacs, see:
https://groups.google.com/d/msg/gnu.emacs.help/Ew0sTxk0C-g/YsTPVEKTBAAJ
https://debbugs.gnu.org/db/20/20703.html
I have applied the suggested patch to etags-tags-completion-table (copied below in completeness for your convenience) and trapped an error case.
I'm triggering the error in an extremely long line of code (46,000 characters!). I presume somebody programmatically generated the line and pasted it into the source. A workaround could be to simply filter such lines at the ctag building or loading stage, just something that deletes "long" lines, whatever that may mean. Probably 500 characters is long enough!
I could also look at adding maximum sizes to my regexes in ctags, but that really isn't a general solution because many ctags patterns do not have such limits.
(defun etags-tags-completion-table () ; Doc string?
(let ((table (make-vector 511 0))
(progress-reporter
(make-progress-reporter
(format "Making tags completion table for %s..." buffer-file-name)
(point-min) (point-max))))
(save-excursion
(goto-char (point-min))
;; This monster regexp matches an etags tag line.
;; \1 is the string to match;
;; \2 is not interesting;
;; \3 is the guessed tag name; XXX guess should be better eg DEFUN
;; \4 is not interesting;
;; \5 is the explicitly-specified tag name.
;; \6 is the line to start searching at;
;; \7 is the char to start searching at.
(condition-case err
(while (re-search-forward
"^\\(\\([^\177]+[^-a-zA-Z0-9_+*$:\177]+\\)?\
\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:\177]*\\)\177\
\\(\\([^\n\001]+\\)\001\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n"
nil t)
(intern (prog1 (if (match-beginning 5)
;; There is an explicit tag name.
(buffer-substring (match-beginning 5) (match-end 5))
;; No explicit tag name. Best guess.
(buffer-substring (match-beginning 3) (match-end 3)))
(progress-reporter-update progress-reporter (point)))
table))
(error
(message "error happened near %d" (point))
(error (error-message-string err)))))
table))