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.
Related
I am using C-x C-s to save a change in a buffer to a file. I am getting the following in my minibuffer:
symbol's variable as value is void: “/home/alex/\.emacs_backups/”
I added .emacs_backups/ a couple of days ago and I altered my .emacs file to:
;; create a backup file directory
(defun make-backup-file-name (file)
(concat “/home/alex/.emacs_backups/” (file-name-nondirectory file) “~”))
This does not happen in every directory. In some directories I can save a buffer change to a file no problem.
You have "smart quotes" in your .emacs. Elisp uses ASCII doublequotes as string delimiters:
(defun make-backup-file-name (file)
(concat "/home/alex/.emacs_backups/" (file-name-nondirectory file) "~"))
I replaced “ and ” with "
After you edit your .emacs, you should evaluate this new function definition with C-x C-e, so that you'll be able to save it without getting an error.
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)
Using Emacs with ido mode enabled on Windows, Emacs tries to save a history file .ido.last when exiting. The file is located in C:/.ido.last, but it fails with a permission denied message. This is strange since I actually have access to that folder. However:
Is there a command to change the directory where the .ido.last file gets saved?
Short answer: (setq ido-save-directory-list-file "/some/file/name").
Long answer:
I keep all the little files that remember Emacs's state in a single directory under the user-emacs-directory. I'm not sure what this is on Windows, but I think it's C:\Users\<username>\Application Data\.emacs.d\. On Unix, it's ~/.emacs.d/. The variable user-emacs-directory should be defined by Emacs, no need to set it.
(setq emacs-persistence-directory (concat user-emacs-directory "persistence/"))
(unless (file-exists-p emacs-persistence-directory)
(make-directory emacs-persistence-directory t))
(setq ido-save-directory-list-file (concat emacs-persistence-directory
"ido-last"))
You may want to look at the no-littering package, which sets better default locations for files like this.
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.
My .emacs contains
(setenv "PATH" (concat ".:/usr/texbin:/opt/local/bin" (getenv "PATH")))
(setq exec-path (append exec-path '(".:/usr/texbin:/opt/local/bin")))
(add-to-list 'load-path "/usr/local/share/emacs/site-lisp")
(require 'tex-site)
(load "auctex.el" nil t t)
(load "preview-latex.el" nil t t)
/usr/texbin is where latex/pdflatex/.. are located.
/opt/local/bin/ is where gs can be found.
And yet when I run preview-at-point, which apparently needs both latex and gs, I get
Preview-DviPS finished at Thu Dec 22 11:25:46
DviPS sentinel: Searching for program: No such file or directory, gs
which means that latex could be found all right, but not gs.
I am not sure whether setting exec-path is necessary, perhaps PATH is enough, but I've set it as a debugging measure.
Why can emacs not find gs even though the directory it's in is in both PATH and exec-path?
If you're setting $PATH inside your Emacs, you might well be on OS X. GUI applications are not started via your shell, so they see different environment variables.
Here's a trick which I use to ensure the $PATH inside Emacs is the same one I see if I fire up a terminal (but see "update" below):
(defun set-exec-path-from-shell-PATH ()
"Set up Emacs' `exec-path' and PATH environment variable to match that used by the user's shell.
This is particularly useful under Mac OSX, where GUI apps are not started from a shell."
(interactive)
(let ((path-from-shell (replace-regexp-in-string "[ \t\n]*$" "" (shell-command-to-string "$SHELL --login -i -c 'echo $PATH'"))))
(setenv "PATH" path-from-shell)
(setq exec-path (split-string path-from-shell path-separator))))
Then simply call the set-exec-path-from-shell-PATH function, perhaps from your Emacs init file. I keep that code on github, BTW.
Update: this code has now been improved and published as an elisp library called exec-path-from-shell; installable packages are available in MELPA.
Try replacing the second line with this:
(setq exec-path (append exec-path '("/usr/texbin" "/opt/local/bin")))
I hit a similar problem, but with a correct PATH, including trailing ´:´. It turned out the internal emacs shell program was missing, resulting in a ´Searching for program: No such file or directory´ message.
Fixed with
(setq shell-file-name "bash").
It appears you're missing a path separator : at the end of your path string.