When I run gdb within emacs (with M-x gdb) and I try to tab-complete directory names, it completes with a space instead of a slash. So, for example:
(gdb) run/mn
tab-completes to
(gdb) run /mnt
when it should tab-complete to
(gdb) run /mnt/
If I run gdb outside of emacs, tab-completion works as expected.
I'm running gdb 7.4.1-debian and emacs 23.4.1 on debian testing.
Any help you could give me here would be greatly appreciated; this is really irritating!
gud-mode retrieves the list of possible completitions by calling gdb's complete command. In your example, the returned list would contain the following (assuming that there's only one directory in your file system that starts with "/mn"):
(run /mnt)
The first part of each entry in the returned list is cut off, so that the remaining complete-list is
(/mnt)
As you can see, this entry returned by gdb's complete command already lacks the trailing slash. Your only hope to fix this would be to either patch gdb's complete command, or to patch Emacs' gud-mode, by somehow detecting that the completed word is a directory and then appending a slash (and suppressing the auto-insertion of the space character).
But of course, you could simply bind the TAB key to a different completion function, potentially one that falls back on the default gud-gdb-complete-command, but perhaps does a different kind of completion when called for.
For this, try putting the following in your .emacs file:
(defun my-gud-gdb-setup ()
(define-key (current-local-map) "\t" 'my-gud-gdb-complete-command))
(defun my-gud-gdb-complete-command (&optional COMMAND PREDICATE FLAGS)
(interactive)
(unless (comint-dynamic-complete-filename)
(gud-gdb-complete-command COMMAND PREDICATE FLAGS)))
(add-hook 'gdb-mode-hook 'my-gud-gdb-setup)
This code binds a new function to the TAB key which first tries to expand the current word as a file, and only if that fails calls the default gud-gdb-complete-command.
Related
Each time when I edit bash script I type a command M-x shell-script-mode. And then I get nice shell code higlighting. How to get it automatically each time I start emacs so I do not have to type the command. When I added (shell-script-mode) to init.el it did not help.
You can set the default major mode to be whatever you want by adding
(setq-default major-mode 'shell-script-mode)
to your init file. That will ensure that any newly created buffer will be in shell-script-mode unless its mode is specified otherwise (e.g. through auto-mode-alist). Whether it's a good idea or not, I don't know: I probably would not want that to be my default setting - but to each her/his own.
One of the simplest ways to have Emacs set the desired mode for a buffer editing a file is to include a special comment in the first line of that file, e.g. for a shell script your first line might be:
# -*-sh-*-
For scripts it is also common, or and often even required, to have an interpreter file comment on the very first line of the file, which of course would preclude having an Emacs mode comment, so Emacs also looks for interpreter file comments and associates those with a major mode, so the first line of your shell script might be:
#!/bin/sh
There are a number of other ways to tell Emacs how to set the buffer mode when visiting a file. See, for example, Emacs Manual: Choosing File Modes
Geiser can be configured to read ~/.guile when running Guile from within Emacs. I would like to append command line options to the argument list passed to guile.
Is there a variable that holds the command line options?
Customize geiser-guile-binary to a list of strings (change the "Value" button to "repeat"). The first one should be "guile" (or whatever the binary for guile is on your system) and the next entries should be strings each containing one argument.
You can double check it by putting (insert (pp (geiser-guile--parameters))) in a scheme file with geiser loaded and then running M-x eval-last-sexp.
I had the same problem, but when I disabled
;;(use-modules (ice-9 colorized))
;;(activate-colorized)
in my ~/.guile-geiser file the problem disappeared.
readline is also not needed within Emacs, just press C-up/down to see the history.
;;(use-modules (ice-9 readline))
;;(activate-readline)
If I'm in a term-mode buffer and there is a file path displayed, how would I go about making the path "clickable", opening the file in a new buffer? It doesn't have to be mouse-clickable, in fact I'd prefer a key binding that works when the point is on the file path. Other than the common case of using ls, this function could be used when viewing a log file. Some debug info contains the file path and line number. Something like lib/library.rb:34 for example. Ideally, Emacs could open a new buffer and move the cursor to line 34.
The short answer is: don't work against Emacs. Let Emacs work for you.
While you can use find-file-at-point or put together something yourself, you will be much better off running make, grep and other stuff which prints "dir/file:pos" using M-x compile or M-x grep.
If you need to interact with your program which prints "dir/file:pos", you can pass a prefix argument to compile and the compilation buffer will be interactive.
If you have an arbitrary program whose output starts with "dir/file:pos", e.g., rails server, all you need to do is run it as (grep "rails server").
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.
I would like to write a small script in ELisp that would:
send a command to a given buffer
get its output
parse it
send it to another buffer
I am struggling with point 2: I cant get the output of a command. For example, if I have a shell buffer on, I can use
(process-send-string "shell" "help\n")
to send "help" to my shell buffer. It will then show the list of the commands available. But how can I get this list to use it somewhere else?
Thanks,
S4m
(buffer-string) returns the contents of the current buffer, so (with-current-buffer <buf> (buffer-string)) will return the contents of <buf>.
I don't know the exact emacs commands for this off the top of my head, but one option would be to do the following:
Set the mark in the shell buffer right below the command line
Execute the command.
Move the point to the end of the file and kill the text between there and the mark.
Move to the destination buffer and yank the text into there.
Have you considered using the shell-command or shell-command-to-string functions?
The don't "send a command to a buffer" like you asked, but they do both allow running a command through a process that will be started just for that purpose and either dumping the output into a target buffer or collecting it into a string.