I've downloaded an already complete .emacs file in order to program in c ++ comfortably.
I have problems with quotation marks "..." that are displayed in two different colors. I think this problem may be linked with this : (thanks to "emacs --debug-init")
Debugger entered--Lisp error: (file-missing "Cannot open load file" "Aucun fichier ou dossier de ce type" "hilit19")
require(hilit19)
How can I get hilit19 or say to emacs to use it ?
Hilit19 was added to Emacs in 1994, moved to lisp/obsolete/ in 2001, and finally removed from Emacs in 2008.
Note that when it appeared in Emacs-19.18 it was already obsolete, since font-lock was added in the previous released (Emacs-19.17) and font-lock is like hilit19 but fancier since it worked "on the fly" (hilit19 only updated the highlighting after an explicit keypress).
So, like triplee said:
You should definitely be very skeptical of anything which requires it today.
Related
I'm having some issues getting company-rust to work the way it should. It loads fine initially, then dies with this error when I attempt to actually use it:
deferred error : (file-error "Searching for program" "no such file or directory" "racer")
The path is correct and I can use it in eshell. I'm on most-recent OSX, with the railwaycat/emacs-mac-port as emacs.
My init.el is here, and I'm not quite sure of what is causing it, and I'm kind of out of ideas.
(setq company-racer-executable "path/to/your/racer")
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)
As the title states, I'm relatively new to Emacs. I tried out several starter kits but went with Prelude and changed a lot of things around.
Anyway, I've been getting a good handle on everything...until this morning I was working and I typed double-quotes. Normally Emacs would insert a second double quotes right after ("") due to the auto-completion, but I must have accidentally changed something with a keystroke and now when I type ", I get \"\".
Thoughts?
Thank you.
This seems to be an issue with smartparens which prelude installs by default (see the file prelude-programming.el. This behavior is described in detail on smartparens wiki. To ensure that smartparens is causing problems you can can do C-h k" this would print about the command acutally run when " is pressed, if the command is sp--self-insert-command then the following should work
Paste this (setq sp-autoescape-string-quote nil) to your *scratch* buffer, go to the closing parenthesis and do C-xC-e, this will disable the behavior for current emacs session.
To disable the behavior for all future emacs session, assuming that you are using prelude, you will need to add the following to your personal config (basically some file inside /path/to/prelude/personal/).
(setq sp-autoescape-string-quote nil)
This will disable the auto-escaping of the string quotes, completely. If you like this behavior and do not want to disable it completely you can do what #steckerhalter suggests C-q" will insert just one parenthesis.
If the above does not solve the issue then try providing following info in your question which may help us debug the issue,
1) The list minor modes active (this can be obtained by doing C-hm).
2) Output of C-hk"
Hope that helps
this sounds a lot like smartparens (https://github.com/Fuco1/smartparens) which is included in Prelude. usually when you are inside "" then it will escape the quotes:
"hahah \"\" bah"
if you want to get a normal " inside quotes you have to use C-q " or disable smartparens with M-x smartparens-mode
If, as you say in a comment, " is bound to self-insert-command, then when you type " what happens is that a (single, unescaped) " character is inserted.
However, I suspect you have some mode turned on that does something additional whenever a " char is inserted. You mention automatic insertion of a second ", for example. That kind of behavior comes from a mode such as is provided by library smart-parens or electric-pair.
And you mention Prelude.
To find out what part of your init file (~/.emacs) is causing the behavior you see, bisect your init file recursively (first comment-out half, to see which half is responsible, then 3/4, to see which quarter is responsible,...). Then, if you still have a question about the responsible code, ask here, providing that info.
When you describe your problem here, it is important to be specific: what Emacs version, what mode(s), what libraries have you loaded,... Whatever might be pertinent. But first narrow down the problem by bisecting your init file to find the culprit.
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 get the following error when trying to open a second instance of emacs:
File error: "Cannot open load file" , "cua"
I guess I don't HAVE to open another instance of emacs (that is the beauty after all), I was just trying to keep some things separated (specifically work - like code and debug - and play - like news).
Would there be any reason I could not open two instances of emacs if I use cua.el?
solved the problem, so i figured i should post in case anyone else is seeing the same thing.
it turns out, it has NOTHING to do with a second instance of emacs. i cant even open a SINGLE instance (i just had been running one instance since before i saw the problem i guess... only noticed this time because of a shutdown).
i changed the following and the problem disappeared. in my .emacs file:
(require 'cua)
(CUA-mode t)
TO
(load-file "cua.el") ;; or if you compiled it (load-file "cua.elc")
(CUA-mode t)
this did the trick for me... although i am not sure why.
thanks to all who commented.
PS - i am using emacs 21.3.1, so i do have an older version. if any readers have the option, justinhj's comment above (about upgrading) is probably the easiest answer. CUA is built into version 22 and above i believe.