I have Emacs on a Kubuntu 15.04 OS and I have a problem in showing the selected region; if I run emacs in the terminal windows with -nw option, I can set marks and I see the selected region highlighted; but if emacs starts in a window, the selected region is not highlighted, though it is still selected (ctrl+w cuts that part). Note that transient-mark-mode doesn't affect this behaviour, whether it is enabled or not.
Do you see this behavior when you start Emacs using emacs -Q (i.e., without an init file)? If not, then recursively bisect your init file until you locate the culprit code. You can do use command comment-region to comment out the region (with C-u it uncomments). Comment out 1/2, then 3/4, 7/8,... until you find the culprit.
If you see a problem using emacs -Q then give a step-by-step recipe to reproduce it.
If not, and if you narrow your init file to locate the problem but you still need more help at that point, report as much as you have found out, specifically. Again, step-by-step specifics help.
Ok, so thanks to Drew I finally managed to resolve this issue!
I had a file with path: /etc/X11/Xresources/x11-common
With the following content:
! $Id$
! load color-specific resources for clients that have them
#ifdef COLOR
*customization: -color
#endif
! make Xaw (Athena widget set) clients understand the delete key
! this causes problems with some non-Xaw apps, use with care
! *Text.translations: #override ~Shift ~Meta <Key>Delete: delete-next-character()
What I just did was moving that file away, running xrdb with an empty input, and everything went fine!
Now I just need to figure out what the content of that file was and what to do if I need to put it back where it was.
Thanks a lot for your precious help, Drew!
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)
when I try to find help topic on a function C-h a , the content will not directly show up.
instead "Type "q" to delete this frame." will occur in the mini-buffer, then nothing show up. but if I type a second time, the content will show up
this is the case for the moment, not sure what configuration is wrong.
It's been a year and a half since you posed the question, and still no answer. Here's my (partial) answer.
As always with such a problem, state your Emacs version and a recipe to reproduce the problem, starting from emacs -Q (no init file). If you cannot repro the problem from emacs -Q then bisect your init file recursively until you find the culprit code.
If you can repro the problem from emacs -Q then people here will be able to help you understand whether it is the expected behavior or not. If not, M-x report-emacs-bug is in order. Even if you are not sure whether something is a bug, you can use M-x report-emacs-bug -- Emacs Dev will let you know. But again, a bug report should preferably include a recipe starting from emacs -Q.
I am using run-octave in Emacs to trigger octave. Something is acting abnormally.
Every time I hit TAB to complete, there would be a tailing ^M; If I edit a .m file using edit a.m, it would start a new frame instead of a new buffer and the prompt is waiting for the closure of that frame so it would not respond to any input. How could I configure .emacs so that run-octave would behave normally?
Any comment is appreciated!
You seem to have two problems. I'm not sure about the trailing ^M, which seems to be caused by some sort of Windows/Unix CR/LF problem, but maybe I can help with the second problem.
The edit command uses the EDITOR environment variable to decide what to run. It seems that yours is either set to emacsclient or has defaulted to it. You haven't said whether you're on Unix or Windows, so I'm going to assume the former: you'll have to change this a bit for Windows.
To avoid the waiting thing, try running octave with a different EDITOR. For example, try out running
EDITOR='emacsclient -n' octave
When you type edit foo, it should bring up an Emacs buffer (if you want a new frame as well, use -c too) but not wait until you're done.
If this fixes things for you, you could change your ~/.bashrc to include the line
export EDITOR='emacsclient -n'
My emacs configuration takes a very long time to load. How can I easily find the offending parts and optimize them?
Very useful package: http://www.emacswiki.org/emacs/ProfileDotEmacs
Just skip loading your init file and let ProfileDotEmacs load/profile it for you:
emacs -Q -l profile-dotemacs.el -f profile-dotemacs
Another solution is ESUP, the Emacs Start Up Profiler. It can profile your config file without leaving Emacs - it accomplishes this by starting a new Emacs as a child process, getting profile information from it.
By using divide and conquer, of course!
Drop the bottom half of your .emacs. See if the speed improves. (If so, the culprit is within the bottom half; otherwise it's in the top half.) Restore the working half. Chop off half of the broken half, and repeat the process until you have isolated the problem.
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.