This is a bit difficult to explain, so please bear with me.
I am running emacs 23.0.60.2 (from CVS) in order to have truetype support. (in case anyone wonders why I'm running the bleeding edge). I'm experiencing some oddness in navigation within documents with this version that I want to have STOP.
When a window is narrow enough that a long line wraps, it used to be that navigating down one line in the text would move the cursor to the next literal line in the file at the same offset into the line. Now, however, the cursor is moved to the next logical line in the window -- which is the continuation of the current line -- at the same relative offset from the window edge. Basically, before it was emacs-like and now it's notepad-like. I don't want notepad-like behaviour.
Does anyone know how to turn this off? Bonus points if you know how to turn it off in .emacs in such a way as to have my .emacs continue to work with emacs 21-22 as well :)
Thanks!
Try to put
(setq line-move-visual nil)
in the .emacs file.
I can't answer the main question, but the bonus question is easy:
(if (>= emacs-major-version 23)
... )
Unfortunately, if you want to be more specific than that (e.g., you want exactly version 23.0.60.2) you'll have to parse emacs-version, which might look something like
"GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.14.3) of 2008-10-13 on rothera, modified by Debian"
Also, if you're running a Debian-based distro, look at the emacs-snapshot-gtk package—the edge might bleed a little less.
Related
I'm using (global-linum-mode t) to present line numbers in Emacs.
This works just fine up-until I use the ctrl + up/down commands (forward-paragraph and backward-paragraph) to navigate a buffer, at which point some line numbers are rendered incorrectly (see attached image).
This occurs only when I use said commands to skip entire segments of code, and the issue immediately disappears (the line numbers are rendered correctly, that is) if I start navigating the buffer by other means.
The issue is present in both C and C++ modes (visualized), and I'm using Emacs 24.3.1 on x86-64 Fedora 19.
While the go-to-line command serves my purposes in terms of navigating compilation errors and warnings, I'd like to keep the line numbers as I find them to be helpful in terms of quickly approximating length of functions.
So far I've found no mention of this problem elsewhere, and I'm unsure of whether or not this is expected behavior of Emacs or if I'm to submit a bug report.
Has anyone encountered the issue or know anything of its origin?
Fix:
The problem may be resolved by invoking (linum-update-current), as portrayed by #lawlist in his answer below. An easy way of repeatedly doing this is to append the command to the execution of forward-paragraph, which may be done using the Emacs Lisp advice feature:
(defadvice forward-paragraph (after forward-paragraph-linum-update)
"Perform (linum-update-current) after jumping forward one
paragraph to ensure line numbers are being rendered
correctly."
(linum-update-current))
(ad-activate 'forward-paragraph)
A few of the lead members on the Emacs development team suggest that linum-mode be avoided for a variety of reasons, and instead they suggest using nlinum-mode: http://elpa.gnu.org/packages/nlinum.html
I personally use a modified version of linum-mode, and I have fixed a few bugs -- if you keep using linum-mode, you will likely need to do the same -- i.e., implement your own bug fixes as you find them. The quickest way to fix the bug you see is to follow your command with:
(linum-update-current)
I'm probably going down the wrong path here, so let me know if I am. I'm trying to build a similar user interface to that which Vim's ctrlp and other plugins use, whereby the user is given a prompt, and as they type, results are shown above the minibuffer prompt line.
I've gotten the minibuffer command handling part working fine with minibuffer-with-setup-hook and a local post-command-hook (easy) and can get the results I want to display (verified by just (message)ing them for now).
If I want to show, say, 10 lines of results above that minibuffer prompt line, should I be somehow prepending text to the minibuffer, or using a separate buffer that I'll close once the command finishes? Any pointers to parts of the manual I should be reading to be on the right track with this?
The "minibuffer" is a normal buffer, so you can modify it by inserting/deleting text into it in the normal way. This said, adding text "before" means basically modifying the prompt which might lead to problems down the line. You'll probably be much better off doing something like
(let ((ol (make-overlay (point-min) (point-min))))
(overlay-put ol 'before-string (format "%s\n" myresults)))
I started to write this as a comment, but it got a bit too long ...
TBH, I feel there is room for a lighter weight version of helm. But the reality is helm is good enough, and someone else has already written it.
Neither I nor anyone else (so far) is motivated enough to rewrite it. What you describe as "God" aspect of it is indeed unappealing. But it is possible to load it (huge as it is, with modern computers, it really isn't an issue), and change settings so it is minimalistic.
ido is a simpler alternative, but the style of UI is not exactly how you described.
When editing an Rnw file in Emacs, I often want to make the region cover a chunk of text that contains an R chunk. For a simple example:
ewr
<<>>=
#
wer
I use transient-mark-mode such that the region is highlighted. But, if I put the point on the first line and hit C-SPC, then use C-n to move the point down, the highlighting disappears when I try to advance the point past the <<. The region I want is still selected, but highlighting seems to fail when crossing the <<. How can I fix this?
Thanks and best regards
I find that your problem shows up when I do what you describe, but it goes away if you scroll down using C-down or C-M-n instead. I think you can even use C-down to get past the R chunk and then C-n to step past lines afterward.
I had the same problem and the solution suggested by fojtasek did not work for me because I had an additional configuration problem. I hope that this might be useful for you and other users. Make sure that if you are using ESS and Auctex that you have fully loaded Auctex. To be more specific, it turned out that when I had previously installed auctex 11.86, I did not correctly load the package. Because I am a novice emacs user, I only managed to load the first of the following two lines:
(load "auctex.el" nil t t)
(load "preview-latex.el" nil t t)
If you have not added the second line, you will only have an Auctex menu but NOT a preview-latex menu.
Thanks to Fojtasek for the C advice. I find C- with the arrow key will keep a contiguous highlight. C-down brings up a page that says "this confusing feature has been disabled by default".
In my opinion, this behavior that OP complained about is a flaw in Auctex, and the fact that Fojtasek has a way to avoid it is helpful, but still it is just a workaround. I don't want Auctex to to this and I don't really want to have to use my left hand for holding down C while scrolling. PITA.
If Auctex needs some special selection tool, they should have to use unusual keystrokes for that. Why impose it on the rest of us who just want to highlight big sections and move them around, whether or not they have <<>> in them.
When I start Emacs, its windows and its minibuffer start up floating on the main frame, leaving a lot of empty space (see: here and here). Any idea of what is going on and how to fix it?
I'm using emacs version 23.1.1 on Xmonad
Thanks!
I get the same thing occasionally when doing a TAB expand in shell mode. I don't end up with an empty mini-buf, it usually has all the contents from the shell expand. The only solution I've found so far is to kill the current shell buffer
You might try C-l (recenter-top-bottom). I've used this over the years as a pretty reliable "repaint" operation that will clear up various detritus that occurs on the frame. It is even more helpful when you do not have a window system.
It looks like an odd interaction between Emacs and your window manager. It's as if Emacs is configuring itself to have a certain number of lines and columns in its active window, but the frame the window manager has allocated it is larger.
Can you try running X without Xmonad (ie. just run startX) and then run Emacs? You won't get frame decorations, but you can still use xterm to start it and see what 'natural' size it gets allocated. With the same Emacs configuration, that would narrow it down to some issue with Xmonad.
It's not obvious from the screenshots, as one is definitely in GUI mode, but the other (green on black) looks like it is in text mode. If you force it to run in text mode (emacs -nw), does it take up the same size? Within the shell, do normal commands take up the entire size of the allocated window?
Are the shell variables COLUMNS or LINES set correctly? Do they match the window dimensions? Assuming you are running bash, is shopt checkwinsize turned on? Do regular commands such as ls wrap at the expected margins and scroll to use the entire window?
It is worth ensuring that text mode is being configured correctly before getting GUI mode to work. I have a hunch the way that Xmonad is managing its window sizing may be the culprit, if it is 'forcing' windows to tile in certain arrangements, and the correct X hints aren't being sent. But - that's all just supposition for now...
This partially works (taken from here):
(defun fullscreen ()
(interactive)
(set-frame-parameter nil 'fullscreen
(if (frame-parameter nil 'fullscreen) nil 'fullboth)))
(add-hook 'emacs-startup-hook 'fullscreen)
The windows get corrected, although the mini-buffer is still larger than the usual.
Sounds like a bug, to me. Consider reporting it: M-x report-emacs-bug. Try to provide a recipe starting from emacs -Q.
In vim, visual block can be recall by 'gv' command so that multiple commands can be applied easily. (such as, comment out, then indent, then do_something_fun).
In Emacs, how can this be achieved?
[C-xC-x] only works when current cursor position stays where previous block ended.
If previous block was changed, the closest is to go through 'point-to-register' and 'jump-to-register'.
Just I am curious if there is an Emacs built-in command making this in one shot.
If Transient Mark mode is off, the region is always active. If it's on (which it sounds like is your situation), you can set mark-even-if-inactive to non-nil to allow region commands to work while the region isn't highlighted.
However, note you also can cycle back through previous mark positions using C-u C-SPC -- this will pop the mark ring. Once you're back to where you want to be, C-x C-x will rehighlight the region you want. (It may take a little bit of playing with this feature to get a feel for it, but it's why I can't switch away from Emacs now.)
If I understand correctly what you are asking for, then you don't need to do anything. When you select a region in emacs, it stays selected until you select a new one. So you could select the region and then perform as many actions as you want.
Sounds like you're looking for the secondary selection, which stays put even as the region might change. (It stays put until you move it.)
See:
the Emacs manual, node Secondary Selection
Emacs wiki page Secondary Selection
library second-sel.el:
Also narrow-to-region (CTRL-x n n ) applies every command from then on just to that region- you can't hurt the rest of the buffer, it doesn't even show. After done editing , widen (CTRL-x n w )to get back the whole buffer.
CMM
If you use evil-mode, just press gv like in vim.
Since the answers here and for other similar SO questions didn't help for me (CUA-mode, Emacs 24, not only indent-rigidly), I continued searching and finally found a reselect-last-region defined in this collection of custom function (starting line 670). That worked like a charm for me - and hopefully does for others still arriving here.