Has anyone found a workaround to the inability of Aquamacs 2.4 to correctly WordWrap at the window boundary?
The modes I use most often are text-mode and latex-mode.
I've removed the built-in hooks of text mode to try and isolate the bug and come up with a workaround:
(remove-hook 'text-mode-hook 'smart-spacing-mode)
(remove-hook 'text-mode-hook 'auto-detect-wrap)
The following code gives me a fancy indicator in the status bar WordWrap, but words are still fragmented at the window boundary.
(add-hook 'latex-mode-hook 'set-word-wrap)
(add-hook 'text-mode-hook 'set-word-wrap)
The following code gives me a pretty status bar indicator of vl WordWrap, but the words are still fragmented at the window boundary.
(setq-default global-visual-line-mode t)
The following code seems to have no appreciable effect:
(setq longlines-wrap-follows-window-size t)
I've really never seen this feature working, so I'm not sure it is even possible with Aquamacs 2.4.
The expected behavior is that words should stay together by automatically wrapping to the next line at the window boundary. As I resize the window, this should happen on the fly. As I type a line, this should happen automatically when I reach the window edge.
Just in case this is a conflict, I'll mention that I have Yasnippets, local and global whitespace, and flyspell all enabled. I also have line numbers, highlight the current line, size indication, and column numbers.
Perhaps someone could just give me the name of the el / elc file that is responsible for this behavior, and I'll take it from a 24.3 version and paste it into Aquamacs 2.4. I am primarily interested in this version because of the ease of which it handles LaTeX documents.
Have you tried in the "Options" menu the submenu "Line wrapping in this buffer"?
Alternatively,
(add-hook 'text-mode-hook #'visual-line-mode)
or
(global-visual-line-mode 1)
The nightly builds of Emacs / Aquamacs have fixed this issue.
Related
I want emacs to start with specific settings by default. I found that I need to edit the .emacs file in my home directory and use LISP language. However I do get some errors. I need to have:
Windows split by vertical line (I work in C++ with headers and source files)
Column number mode
Cua-mode enabled (to work with normal copy, cut & paste shortcuts)
That's what I have in my .emacs file:
(column-number-mode)
(load "cua-mode")
(CUA-mode t)
(split-window-right)
I'ver tried coding two middle settings in one - (cua-mode). It didn't work out well.
The column-number-mode works, cua does not load and my window is split horizontally (top and bottom window). Where is my error? Thanks for feedback.
From the comments to the question:
if you're using Emacs 24.1 or later,
(column-number-mode)
(load "cua-mode")
(cua-mode t)
(split-window-right)
but if you're using an earlier version,
(column-number-mode)
(load "cua-mode")
(cua-mode t)
(split-window-horizontally)
By the way, the split-window-horizontally also works in later versions of Emacs (I'm using Emacs 25.2.1).
Is there a proper predicate for determining whether the window has focus in the mode line? I'm trying to do some things in my mode line that require more flexibility than just using mode-line-inactive.
I've been doing:
(defun window-has-focus-p ()
"When called in eval sexp in mode or header line template,
returns true if this is the active window."
(eq
(frame-selected-window)
(get-buffer-window)))
And it worked very well on two of my computers for months (Windows 7 and Debian). However, I tried using it on another Debian box yesterday and it reported t in every mode line for every window... totally broken.
I haven't been able to find a standard predicate call for this purpose, and I can't figure out why this hacked-up one seems to work on some devices and not others. Additionally, I did evaluate (force-mode-line-update t) with M-: and that did not help.
Emacs version is 24.3
While the mode-line-format is evaluated for a given window, this window is temporarily made the selected-window. In Emacs<=24.3 this was made only halfway: selected-window was changed, but not frame-selected-window. This meant that temporarily (frame-selected-window) was not equal to (selected-window) and breaking this (normally) invariant was a source of various corner case bugs. So we fixed it in 24.4, which means that your code broke.
To make it work in 24.4, you need to save the "selected-window" as seen by the user before the mode-line-format is processed.
You can do that with
(defvar my-real-selected-window nil)
(add-function :before pre-redisplay-function
(lambda (_wins) (setq my-real-selected-window (selected-window))))
So you can then use my-real-selected-window in your mode-line-format to know which window is the one that should be highlighted specially.
I have been using this in my configuration
;;; active modeline detection hack
(add-hook 'post-command-hook
(lambda ()
(when (not (minibuffer-selected-window))
(setq powerline-selected-window (selected-window)))))
Maybe the post-command-hook is not the most elegant solution, but is working correctly for me.
Is there an equivalent to the fill-column variable for the "Wrap" mode (visual-line-mode) in Emacs? If not, how could I set a limit on the length of visual lines when the window/frame of the buffer is wider ?
In response to this question I created a minor mode called window-margin that accomplishes what #Stefan suggested in his answer.
Turn on window-margin-mode with:
(add-hook 'text-mode-hook 'turn-on-window-margin-mode)
The way you can still do it without installing window-margin is to use the longlines-mode that ships with Emacs, but is being phased out since there are some problems with longlines-mode, but here's the old way to do it if you want:
Turn on longlines-mode with something like:
(add-hook 'text-mode-hook 'longlines-mode)
which wraps text at the fill-column.
longlines-mode has been removed. For visual-line-mode, the simplest way is to make the window as narrow as you want it to be. You can do that with C-x 3 and then adjusting the size of the window. Or you can set a wide margin or wide fringes.
Emacs 23.2 in emacs-starter-kit v1 has C-x C-i (or ido-imenu) (similar to Sublime Text's Cmd+R). Emacs24 in emacs-starter-kit v2 lacks this function. I found this github issue and a fix, which try to recreate the functionality. While this ido-imenu works in elisp-mode, it stopped working in ruby-mode. I get:
imenu--make-index-alist: No items suitable for an index found in this buffer
Has anyone figured out how to get this to work?
Why was this taken out of Emacs24?
Is there a new replacement for this function?
Since the function is part of ESK (as opposed to something budled with Emacs) you'd probably do best to report the bug upstream. On a related note ESK main competitor Emacs Prelude offers the same functionality (bound to C-c i by default) and it seems to be working fine with ruby-mode in Emacs 24. Here you can find more on ido-imenu.
So I finally figured it out, after reading the Defining an Imenu Menu for a Mode section on emacs-wiki again.
Short answer: you need to add this bit to your customization. Feel free to add more types to the list (I am happy with just methods).
(add-hook 'ruby-mode-hook
(lambda ()
(set (make-local-variable imenu-generic-expression)
'(("Methods" "^\\( *\\(def\\) +.+\\)" 1)
))))
Longer answer: I first tried to define a ruby-imenu-generic-expression function and set that to imenu-generic-expression by using the ruby-mode-hook:
(defvar ruby-imenu-generic-expression
'(("Methods" "^\\( *\\(def\\) +.+\\)" 1))
"The imenu regex to parse an outline of the ruby file")
(defun ruby-set-imenu-generic-expression ()
(make-local-variable 'imenu-generic-expression)
(make-local-variable 'imenu-create-index-function)
(setq imenu-create-index-function 'imenu-default-create-index-function)
(setq imenu-generic-expression ruby-imenu-generic-expression))
(add-hook 'ruby-mode-hook 'ruby-set-imenu-generic-expression)
This however did not work (I would get the same error as before). More reading of the Defining an Imenu Menu for a Mode section showed me the way. Now, I'm not an elisp expert, so here's my hypothesis: basically, the above method works for modes where the
major mode supports a buffer local copy of the “real” variable, ‘imenu-generic-expression’. If your mode doesn’t do it, you will have to rely on a hook.
The example for foo-mode made it clear how to do it for ruby-mode. So it appears that ruby-mode does not have a buffer-local copy of the real imenu-generic-expression variable. I still can't explain why it worked in Emacs 23.2 (with ESK v1) but does not on Emacs24, but hey at least I found a working solution.
I'm using emacs with cvs and have cvs mode enabled. I'd like to get line-by-line highlighting of changes from the latest version in CVS. I've seen this done in intellij where there is a green indication for lines added and another indication for lines modified and a third symbol for lines deleted.
Is there a cvs highlighting mode for emacs to show changes from the latest version of cvs? I'm not looking for a cvs diff type functionality that would open in a new buffer, but something that would indicate in my current buffer what lines have been modified.
In the following image there is a blue rectangle on the left side in what Intellij calls the "gutter" to indicate that the code is different than what is in source control.
(source: jetbrains.com)
I'm looking for similar functionality in emacs.
You can now check out diff-hl, which provides highlighting on the left window fringe.
So far I've tested it only on a few modern DVCSes, but if you're still using CVS, and it doesn't work as well, please file an issue.
Here's another answer that doesn't do what you want either, but may be useful.
C-x v g
runs the command vc-annotate.
That'll pop up a new buffer (I know, you didn't want one), but it'll have all the lines marked with who touched them when. And, bonus, they're color coded with a heatmap (red is most recent, blue is least), for easy identification of recent changes.
Of course the built-in version of vc-annotate doesn't scroll the buffer appropriately, so you'll want this advice:
(defadvice vc-annotate (around vc-annotate-and-scroll)
"scroll buffer to view current line in the annotated buffer"
(let ((pos (count-lines (point-min) (point))))
ad-do-it
(let ((orig-window (selected-window))
(window (other-window-for-scrolling)))
(select-window window)
(goto-line pos)
(select-window orig-window))))
(ad-activate 'vc-annotate)
You want vc-diff, which is on C-x v = by default. This gives you raw diff output in a temp buffer. The buffer uses diff-mode, which has a few neat tricks ... for example, you can use C-c C-e to apply the diff as a patch to another file. Use describe-mode (C-h m by default) in the diff buffer to find the other tricks.
Perhaps you'd like Ediff, which appears to do exactly what you want.