I am using emacs 24.3.1 to write programs (in C and C++ mode).
After compiling the current buffer, I run below command: M-x gud-gdb. Emacs gives a prompt like below:
gdb --fullname prog
However, sometimes the "prog" name is not the same as the executable name compiled from current buffer.
e.g. I completed five programs prog1, prog2,... prog5, and is currently working on prog6. But M-x gud-gdb gives me gdb --fullname prog5. (I want prog6 instead.)
Is there a way to correct this? Specifically, "correct" means forcing gud-gdb to use current buffer's name (without suffix) as the prog name.
Thanks in advance.
I think emacs uses a heuristic (based on what executable file is more recent or something like that) to figure out the default program to offer.
If your preferences are very specific you could define and use this function:
(defun my-gud-gdb ()
(interactive)
(gud-gdb (concat "gdb --fullname "
(file-name-sans-extension (buffer-file-name (current-buffer))))))
This function will execute gdb on a file named like the file you are editing without extension.
gud-query-cmdline accepts filename as an optional argument, which isn't served yet.
Patch below should provide it.
Make sure, file-permissions are set to executable
--- gud.el Sun Mar 17 12:52:42 2013
+++ gud.el Tue Jun 3 10:06:11 2014
## -716,7 +716,7 ##
"Run gdb on program FILE in buffer *gud-FILE*.
The directory containing FILE becomes the initial working
directory and source-file directory for your debugger."
- (interactive (list (gud-query-cmdline 'gud-gdb)))
+ (interactive (list (gud-query-cmdline 'gud-gdb (and (file-executable-p (buffer-file-name))(buffer-file-name)))))
(when (and gud-comint-buffer
(buffer-name gud-comint-buffer)
Related
I'm using ps-print-buffer-with-faces to print out code with colored syntax highlighting (in emacs).
This works fine if I call ps-print-buffer-with-faces interactively (using M-x for example). I've also got it working from a bash script so that I can print in color from the command line. No problem.
However, I want to be able to perform this from cron, or possibly from a Makefile (i.e. without X11)
I've tried using the emacs -nw option and it complains that stdin is not from a tty and will not continue.
When I use the emacs --batch option, it appears that it is working, but the resulting postscript file has no colors at all.
Does anyone know how I can get ps-print-buffer-with-faces to obtain colors without X11?
This really bring back some memories -- I wrote a package like that back in the 1990:s, unfortunately, I have lost the source code (this was long before I started using a version control system).
The key to using font-lock in batch mode is to fool it into believing that it's in interactive mode, by setting noninteractive to nil.
I just threw together the following, is saves a postscript file named ORIGINAL_BASENAME.ps. You can easily modify this to print to the printer directly, by not passing the file name parameter.
#!/usr/bin/emacs --script
(defun ps-batch-print (files)
(dolist (source files)
(unless (file-exists-p source)
(user-error "File not found: %s" source))
(find-file source)
(let ((noninteractive nil))
(font-lock-mode 1))
(ps-print-buffer-with-faces (concat (file-name-nondirectory
(file-name-sans-extension source))
".ps"))))
(ps-batch-print command-line-args-left)
As always, Emacs packages print tons of messages irrelevant when in batch mode. You can get rid of them by redirecting stderr using 2> /dev/null, if you are using a UNIX-like system.
This question already has answers here:
How can I have term.el (ansi-term) track directories if using anyhting other than bash
(2 answers)
Closed 8 years ago.
It's a very strange problem. I think it must caused my incorrect configuration of ansi-term, but i still can't find out where it is.
The issue is: when i in ansi-term and press M-x find-file, the prompt isn't current directory but the path i entered in my previous find file action. So when i change directory, it still display the same directory. So i have to enter the current directory every time. But it works very well in M-x shell and M-x eshell
Does the same thing happen when you start Emacs without your init file, i.e., emacs -Q? If so, that's the designed behavior or (especially if you use a development snapshot) perhaps an Emacs bug.
If not, then bisect your init file recursively to find out which part of it causes this behavior. To do that, use, e.g., command comment-region (see prefix arg in doc) to comment and uncomment a block of text. Comment out 1/2 of your init file, then 3/4, then 7/8,...,
each time testing whether the uncommented portion causes or removes the problematic behavior. You will very quickly identify what causes the behavior.
Because the path of emacs is different from that of term, it can only be changed by use the emacs command "cd".
So to solve this problem, I add the following code to my emacs configure file. The method is
find the pid of current term
find current working directory(cwd) of this pid.
I use multi-term, I think the method will be similar on ansi-term.
(defadvice term-send-input (after update-cwd)
(let* ((pid (process-id (get-buffer-process (current-buffer))))
(cwd (shell-command-to-string
(format "lsof -p %d -Fn | awk 'NR==2{print}' | sed \"s/n\\//\\//\" | tr -d '\n'" pid))))
(cd cwd)
(message (concat "change emacs path to: " cwd))))
(ad-activate 'term-send-input)
Then you can bound the key of term-send-input to <enter>. When you press <enter> in term, the emacs will change to the same path with the current path of term.
BTW, I use Mac Os. If you are on Linux, you can use the following code to find cwd.
(cwd (file-truename (format "/proc/%d/cwd" pid)))
Assume I edit in Emacs a file t.txt in my home directory. Then
ESC-: buffer-file-name produces /Home/fcihh/t.txt How can I extract the file name part t.txt from that?
According to this link I thought I should be able to write
ESC-: (file-name-base buffer-file-name). But this produces the error
Lisp error: (void-function file-name-base)
I am using GNU Emacs 23.3.1 on Ubuntu 12.04.
Unfortunately file-name-base has been introduced in Emacs 24. Here is its definition, from lisp/files.el:
(defun file-name-base (&optional filename)
"Return the base name of the FILENAME: no directory, no extension.
FILENAME defaults to `buffer-file-name'."
(file-name-sans-extension
(file-name-nondirectory (or filename (buffer-file-name)))))
Both file-name-sans-extension and file-name-nondirectory should be available in Emacs 23.
If you want the base name with extension you only need file-name-nondirectory.
I encountered strange behaviour of expand-file-name function on windows during installation of last cedet using el-get. The issue is related to generation of autoloads.
The autoload.el on last emacs 24.1.50 contains the following function:
(defun autoload-generated-file ()
(expand-file-name generated-autoload-file
;; File-local settings of generated-autoload-file should
;; be interpreted relative to the file's location,
;; of course.
(if (not (local-variable-p 'generated-autoload-file))
(expand-file-name "lisp" source-directory))))
In my case generated-autoload-file is:
"/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
as I have $HOME$ environment variable pointed to C:/home/ngulyamov. In this case above function returns:
"d:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
due to source-directory contains:
"d:/devel/emacs/emacs-bzr/trunk_jenkins/".
As you can see it changes drive letter from C: to D:.
At the same time on emacs 23.3 this function returns semi-correct value as source-directory contains value:
"c:/Users/Sean/Downloads/emacs-23.3/".
According to expand-file-name function description:
(expand-file-name NAME &optional DEFAULT-DIRECTORY)
Convert filename NAME to absolute, and canonicalize it.
Second arg DEFAULT-DIRECTORY is directory to start with if NAME is relative
(does not start with slash or tilde); if DEFAULT-DIRECTORY is nil or missing,
the current buffer's value of `default-directory' is used.
The paths on Windows never start from slash or tilde.
Now my questions:
1. Does expand-file-name function behaviour correct on Windows?
2. Why source-directory contains value of developers paths?
Could we consider expand-file-name as buggy on windows? Or it is just wrongly used in autoload.el?
Thank you in advance.
Finally I figured out the reason. The issue is coming from Makefile of cedet which uses $(abspath) functionality of make 3.8. The cygwin version of make in this case returns UNIX way of path, i.e. /home/ngulyamov/... which then replaces by source-directory root in autoload by d:/home/ngulyamov/.... The GnuWin32 version of make works correctly but by strange reason I have the following issue:
C:\home\ngulyamov\.emacs.d\el-get\cedet>\gnuwin32\bin\make all
Removing loaddefs.el files from subprojects.
Generating autoloads.
make[1]: Entering directory `C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet'
> autoloads
Wrote C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/loaddefs.el
Loading vc-bzr...
Generating autoloads for C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/cedet-android.el...
Memory exhausted--use C-x s then exit and restart Emacs
make[1]: *** [autoloads] Error 127
So dirty fix is specifying source-directory in autoload.el itself like:
(setq-default source-directory "C:/home/ngulyamov/.emacs.d/")
Anyway, why source-directory is pointing to developer's computer path is remaining open.
I want to have a make-shells command in emacs that will open a number of emacs-shell buffers, each with its own working directory. The idea is that for each project I'm working on, I have a shell that starts out in that project's directory, so I can easily switch between them.
Currently I have this code:
(defun shell-dir (name dir)
(interactive "sShell name: \nDDirectory: ")
(shell name)
(switch-to-buffer name)
(comint-send-string (current-buffer) (concat "cd " dir "\r"))
(sleep-for 0 10)
(dirs))
(defun make-shells ()
(interactive)
(shell-dir "project1" "~/proj/project1")
(shell-dir "project2" "~/proj/project2")
(shell-dir "project3" "~/proj/project3")
(delete-window))
This is pretty ugly, though, and half the time (dirs) doesn't pick up the correct path, so tab completion breaks until I re-run it manually. Is there a built-in way to set the current working directory of the emacs shell? Or would something like CEDET (plus less reliance on the shell vs. emacs modes) be a much better solution to this?
I experienced similar problems with the current directory tracking provided by Emacs, so I wrote one which solves the problem once and forever.
Check it out here.
The short version of what it does is that you modify your shell prompt to include a full path to the current directory (only when running inside Emacs), and the Emacs shell buffer will use that.
This means you never have to do M-x dirs again.
There's also the package dirtrack (shipped with Emacs) which does the same thing.
I like my version better because it removes the path from the prompt. I don't want to see the entire path in my prompt as my current directory is often very long.
Once you use one of the above two solutions, you can simplify your shell-dir routine to be:
(defun shell-dir (name dir)
(interactive "sShell name: \nDDirectory: ")
(let ((default-directory dir))
(shell name)))
One more answer... I found there was a way (on Linux) to make Emacs figure out the current directory properly, by using the /proc filesystem.
http://www.emacswiki.org/emacs/ShellDirtrackByProcfs
That way, you just have to start up the shell in whatever directory and Emacs will automatically figure it out and get the tab-completion etc. right.