I'm new to Clojure, lein and spacemacs. I'm attempting to get the cider-jack-in repl going in spacemacs, but it's failing to load. After searching online, I think the solution to this issue is here. Specifically,
"For anyone else running into this issue, this can be fixed by setting cider-lein-parameters to "repl :headless :host localhost" (the default value is "repl :headless :host ::")"
My problem is that I have no idea where the cider-lein-parameters file is, or if it even is a file. And because I can't even locate it, I cannot edit it. I've done extensive searches on this, but haven't found anything useful. Can anyone guide me with a basic explanation of what this is and how I can edit it? Is this a spacemacs thing? Or a lein thing?
Any and all help would be greatly appreciated! Thank you!
Press M-x (Alt-x), then enter set-variable command
Select or enter cider-lein-parameters variable name
Enter its value in double quotes. e.g. "new value"
Related
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!
I looked into this page: http://emacswiki.org/emacs/CopyWithoutSelection.
I copied the exactly same code to my .emacs. Somehow, only the copy-line and copy-paragraph work. But what I really want is copy-word. Every time I ran copy-word, I got an error like: "wrong type argument: integerp, nil". The weird thing is the only difference between copy-word and copy-line is copy-thing backward-wordforward-word arg instead of beginning-of-line andend-of-line, and all of them are build-in. I was wondering why the copy-line works while the copy-word doesn't.
Can anyone help me out of this?
Hello this isn't a coding question but...
I ssh through my mac using X11, and I am using emacs. I am trying to use the "ALT" key for combination but it seems to not be working. I have tried using the "option" key, and "FN + option" both seems to not work.
I had the same problem before. The hint on http://hints.macworld.com/article.php?story=20040425231058862 helps me.
To summarize, you should use xmodmap to remap alt / option in X11.
Put the following in your ~/.Xmodmap file:
clear Mod1
keycode 66 = Meta_L
add Mod1 = Meta_L
If the emacs instance is somewhere else, which is how I read your question, then it maybe that emacs isn't receiving the correct key when you press alt.
There are a variety of fixes on http://www.emacswiki.org/emacs/EmacsForMacOS#toc20.
However, I'd say that you're probably approaching the problem from the wrong direction. Have you considered running emacs locally, and using TRAMP mode edit the remote files on the local machine?
try putting this in ~/.emacs
(set-keyboard-coding-system nil)
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've checked my elisp files to make sure that I do not have any bindings that contain Shift+R (and I have not found any). I expect SHIFT+R to print an uppercase character, but instead I get R R undefined inside of the Emacs command line. This is only in C/C++ major modes.
Any suggestions?
Update: Describing the key shows that it is undefined. How would I define it for the normal, expected use (capitalizing the letter R)?
I assume by the 'expected use' you mean to insert the 'R' character. For this, you'd need to bind the key to 'self-insert-command':
M-x global-set-key R self-insert-command
Or, in your .emacs or .emacs.d/init.el file:
(global-set-key "R" 'self-insert-command)
Of course, this should be the default....
I'm getting a little deja-vu here and if memory serves the behavior I encountered some years ago was that (on Windows) certain accessibility settings unset or changed the keycode for the right shift key. Sorry I cannot be more specific but maybe this will stimulate someone else to come up with the real answer. A test you can make: does the behavior work with both shift keys or just one? If the answer is just one shows the bad behavior, is that bad behavior shown with all keys?
Try C-h k (describe-key), then press Shift-R. describe-key will then tell you what is bound to that key. At least that will give you a hint as to whether or not there is an active binding. If there's a binding, perhaps it will give you a hint of something else to search for in your startup files.
You sound like you're having the same problem I had. Typing Re... in any html buffer would try to execute an R- command, when every single R-* command was undefined. Turned out that I had a typo in my .emacs file. I had a global-key-map set to (kbd "REF") instead of (kbd "RET"), and fixing it made the problem immediately vanish. So I'd recommend checking for anything similar in your .emacs file.