What I'd like that to do, is when I'm on a line of source such as: foo
And I hit a "jump" key, it should match href="foo.html" and open the file c:/project/root/templates/foo.html.
I've found jump.el (package 'jump' in emacs 24) and am trying to get defjump to work:
(require 'jump)
(defjump
'my-follow-ref
'(("href=\"\\1\"" . "templates/\\1"))
"c:/project/root/"
"Follow a logical link from one part of the source to another.")
My code is based on the example in the help, but I'm getting stuck on a pretty basic emacs lisp error:
mapcar: Wrong type argument: listp, quote
What am I doing wrong?
There is no jump.el in the emacs 24 source tree, and google is no help, but, I guess, your problem is unnecessary quoting: defjump is probably a macro.
Chances are this will work:
(defjump
my-follow-ref
(("href=\"\\1\"" . "templates/\\1"))
"c:/project/root/"
"Follow a logical link from one part of the source to another.")
Related
My Current Workflow
I need to use 'doseq'
I don't remember it's args.
I go to clojuredocs , lookup 'doseq', and look at the examples.
My Ideal Setup
Inside emacs, I type some magic key combo, I type in doseq,
and it EXTRACTS EXAMPLES FROM A LOCAL MIRROR OF CLOJUREDOCS
and presents it inside my emacs browser.
What I found via Google:
https://www.reddit.com/r/emacs/comments/450x84/a_clojuredocsorg_for_emacs/
Basically other people also want this.
My Question:
Is there anyway to do this in emacs?
Thanks!
I use cider-grimoire. In Spacemacs, I just type the leader key, followed by hg. Behind the scene, cider will perform a search on conj.io and return the result in another Emacs buffer.
Late to the party, but here it is:
https://github.com/mbuczko/helm-clojuredocs
It is helm-based solution which redirects to the clojuredocs.org displaying documentation of given search phrase (if found). Most useful when used with helm-clojuredocs-at-point function which simply searches for phrase under the cursor.
If you use cider, C-c C-d C-d on a var will show you the docstring for that var. Not exactly what you're describing but for many use-cases the docstring is enough to figure out the arguments to a function.
cider will also show the arguments to the current function (under cursor) in the echo area.
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.
So, way back in January, I went here:
http://emacsformacosx.com/
I downloaded Emacs and have been using it on my Mac and I like it. I've started trying to get into Elisp programming. To learn more, I'd like to look up some functions. So for instance I do:
C-h f
and then type "scroll-down"
This gives me the following text:
>scroll-down is an interactive built-in function in `window.c'.
>
>It is bound to <kp-prior>, <prior>, C-1, C-x C-1, M-v.
>
>(scroll-down &optional ARG)
>
>Scroll text of selected window down ARG lines.
>If ARG is omitted or nil, scroll down by a near full screen.
>A near full screen is `next-screen-context-lines' less than a full screen.
>Negative ARG means scroll upward.
>If ARG is the atom `-', scroll upward by nearly full screen.
>When calling from a program, supply as argument a number, nil, or `-'.
And the text "window.c" is a link. So I click on the link and I get:
find-function-C-source: The C source file window.c is not available
I'm getting this error a lot while doing a lot of different things. Where do I find the right path, and how do I tell Emacs what that path is?
I did just recently install some ELPA packages, so maybe one of them is causing some chaos?
The variable source-directory will point to the location where the C sources are. If you have a separately downloaded copy, you'll have to point this variable to that directory.
Most packagers don't include the sources, or split them off into a separate package. Install the sources (and maybe tweak an init script to tell Emacs where you put them, if it's not the default location. The pertinent variable is find-function-C-source-directory).
If you didn't manually build Emacs from the source code and patch the C source code, value of source-directory or find-function-C-source-directory would be wrong.
You can manually download Emacs source code, unpack it somewhere and set above two variables accordingly like following
(setq source-directory "/path/to/your-emacs-repo")
;; OR
(setq find-function-C-source-directory "/path/to/your-emacs-repo/src")
GNU Emacs source code and development is hosted on savannah.gnu.org. You can find all the tags here and download the one that matches your M-x emacs-version.
How can I make Emacs to complete words that are in C include files ?
#include <stdio.h>
int main(){
print//<-- this is where I want it to complete printf
What's the simplest way? (something simpler than Cedet)
First generate tags for the source and include files you'd like to be able to autocomplete for. See my blogpost for tips on using tags if you didn't use tag tables before.
Now if you have a TAGS table that includes the stdio.h, then you can autocomplete 'printf' using the command `complete-tag'.
Perhaps bind `complete-tag' to a key:
(global-set-key [f3] 'complete-tag)
Unlike complete-tag, dabbrev-expand, or hippie-expand (which does dabbrev-expand like things), the CEDET suite does exactly what the question describes. When asked to perform a completion, it looks and sees that you have included stdio.h, and then looks there for possible completions.
CEDET does a lot of other things related to completion as well which will provide very focused and correct suggestions, not just vaguely similar suggestions. A side affect is that CEDET takes more effort to setup. You need to teach it where you include files are, for example, and sometimes how to deal with macros, and what the project you are working on is like.
There is more detail on this here:
link text
You might want to try out M-/ (dabbrev-expand). This command attempts to complete the identifier immediately preceding the point (ie, where your cursor is) using the contents of the current buffer and then the contents of other buffers of the same mode. If the first completion offered isn't the one you want, just keep typing M-/. If you have the habit of keeping a single emacs session open continuously (which, if you don't have, you should really acquire), and have a handful of files from the current project open, you're quite likely to be able to find an the expansion you want for any particular prefix.
So, to answer you're original question, M-/ will find the printf completion you're looking for if (a) you've used printf anywhere else in the buffer you're editing, or (b) it appears in any other .c or .h file you have open in emacs.
You might also try hippie-expand, which has additional options regarding where it looks for completion information. I bind M-/ to hippie-expand, and then modified the order of the elements in hippie-expand-try-functions-list as follows:
(global-set-key (kbd "M-/") 'hippie-expand)
(setq hippie-expand-try-functions-list '(try-expand-dabbrev try-expand-dabbrev-all-buffers try-expand-dabbrev-from-kill try-complete-file-name-partially try-complete-file-name try-expand-all-abbrevs try-expand-list try-expand-line try-complete-lisp-symbol-partially try-complete-lisp-symbol))
This makes hippie-expand act like the normal M-/ at first, but repeated presses will yield more possible expansions.
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.