On Debian Wheezy, Emacs 23.3.1, running ediff-files with a file that is missing a newline at the end results in the error \ No newline at end of file (I hope that's the correct translation; it's German \ Kein Zeilenumbruch am Dateiende. on my computer.)
Is it possible to have just a warning instead, so that I can see the diff and work on it (and fix the missing newline)? It's just a bit tedious to first have ediff fail, then open the file, add the newline, ediff again.
Try changing the value of the variable ediff-diff-ok-lines-regexp to include the German text ("Kein Zeilenumbruch am Dateiende"):
(setq ediff-diff-ok-lines-regexp
(concat
"^\\("
"[0-9,]+[acd][0-9,]+\C-m?$"
"\\|[] "
"\\|---"
"\\|.*Warning *:"
"\\|.*No +newline"
"\\|.*missing +newline"
"\\|.*Kein +Zeilenumbruch +am +Dateiende"
"\\|^\C-m?$"
"\\)"))
Update: Looking at the source code, it does seem that Ediff doesn't make any attempt to deal with the issue of localization of messages from diff. It should also be possible to work around this by wrapping diff in a shell script, e.g:
#!/bin/bash
LANG=C diff $*
..then customising the ediff-diff-program to call the wrapper instead:
(setq ediff-diff-program "~/bin/my-diff.sh")
Other code in the Emacs source directory lisp/vc does seem to handle this, for example vc-hg-state:
(defun vc-hg-state (file)
"Hg-specific version of `vc-state'."
...
(with-output-to-string
(with-current-buffer
standard-output
(setq status
(condition-case nil
;; Ignore all errors.
(let ((process-environment
;; Avoid localization of messages so we
;; can parse the output.
(append (list "TERM=dumb" "LANGUAGE=C")
process-environment)))
...
It seems a bit strange that Ediff doesn't also do this, but perhaps I'm missing something.
Ok, I found out what's wrong, and sadly, it's quite obvious: my environment has LANG=de, therefore when Emacs invokes diff, the warning message is returned in German as well, and Emacs, not recognising this “unkown” message, fails.
Starting emacs with LANG=C emacs works around this problem. However, I consider it a (quite silly) bug of emacs to make assumption on the user's language being English.
Related
Every time I try to create or visit a file with a ".txt" extension, I get a stack trace like the following:
Debugger entered--Lisp error: (wrong-number-of-arguments quote 0)
quote()
set-auto-mode-0(quote nil)
set-auto-mode()
normal-mode(t)
after-find-file(nil t)
find-file-noselect-1(#<buffer file.txt> "~/path/to/file.txt" nil nil "~/path/to/file.txt" (24122033 2049))
find-file-noselect("/home/me/path/to/file.txt" nil nil)
ido-file-internal(raise-frame)
ido-find-file()
call-interactively(ido-find-file nil nil)
The buffer "file.txt" is open, however, in fundamental mode. This happens whether I use ido_find-file or M-x find file.
I tried to fix this by adding the following line in my init.el file:
(add-to-list 'auto-mode-alist '("\\.txt$" . text-mode))
...and I've changed the txt to [tT][xX][tT], switched out a \\' for the $, and tried fundamental-mode instead of text-mode; but no combination of changes seems to make the error go away.
I'm working with GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2), on xubuntu linux.
I presume the error starts with set-auto-mode(), but I don't know that for sure, and I don't know why the parens would be empty there. Has anyone else had this problem, or know what I'm doing wrong here?
If it's an auto-mode-alist issue, evaluate the following to confirm which mode Emacs is getting from that:
(assoc-default "foo.txt" auto-mode-alist 'string-match)
If it's nil, that's certainly the problem, and you do have a problem with your auto-mode-alist configuration.
It's probably not that, though -- there are a bunch of other things Emacs tries in set-auto-mode, so you likely need to narrow it down.
Try this:
M-x find-library RET files RET
M-x eval-buffer RET
C-xC-f foo.txt RET
Having evaluated the functions (n.b. you could really just evaluate set-auto-mode), you should now get a far more detailed stack trace when you hit the debugger, so you'll be able to figure out exactly where in set-auto-mode the call to set-auto-mode-0 is happening, and consequently which mechanism is resulting in a nil value for the major mode symbol.
(If you're unsure how to proceed from there, paste the stack trace into the question.)
I suspect that the problem is coming from a faultly local variables declaration in your file /home/me/path/to/file.txt. Do you have a local variables declaration in that file, and does it perhaps contain a quote (') that should not be there?
But I agree with the good advice that #phils gave, for tracking this down. There are a few different ways in which set-auto-mode can try to determine the mode. You will need to find out which one was being used (unless perhaps my guess helps).
After adding the following code in my .emacs file, comes up some error during startup of emacs. I am a newbie of emacs, is there some one can help me figure out where are the errors come from?
Added code in .emacs:
;; Auto-saving the Desktop
(require 'desktop)
(desktop-save-mode 1)
(defun my-desktop-save ()
(interactive)
;; Don't call desktop-save-in-desktop-dir, as it prints a message.
(if (eq (desktop-owner) (emacs-pid))
(desktop-save desktop-dirname)))
(add-hook 'auto-save-hook 'my-desktop-save)
Errors:
Looking at the function definition for what's breaking, it seems that the error is that prj-file is NIL in line 492. (The other expand-filename call in the function shouldn't ever have a nil, since it's the car of a non-nil list of filenames).
Now, prj-file is the first filename in /home/shenyan/Test/memcached-1.4.11 matching the regexp "\\(Root\\)?ProjStep.ede" and presumably there isn't one. Since memcached presumably doesn't have an EDE project file, what's gone wrong must be that line 508's call to ede-project-p did something weird when called with this subdirectory of /home/shenyan/Test/.
I can't work out exactly why that happened, but you can debug things quite easily. First bring up your *scratch* buffer to type emacs lisp easily. To check my guess, insert the following code into the buffer
(ede-directory-project-p "/home/shenyan/Test/memcached-1.4.11")
and run it by hitting C-x C-e with cursor on the closing bracket. If it returns nil I was wrong. Otherwise, you've found the culprit and should probably debug it further by hunting through the bits of ede-directory-project-p in ede-files.el.
Probably what's going on is that your /home/shenyan/Test/ directory has something that tells EDE to search subdirectories (or maybe that's the default?) and then the memcached subdirectory has a file whose name makes EDE think it should be searched for a project file. If you work out exactly what happened, you might consider submitting a bug to the EDE developers: they probably shouldn't error out if the project file doesn't exist.
I've upgraded to Emacs 23.3 and now the *Compile-Log* buffer opens constantly with errors like:
Warning: `font-lock-beginning-of-syntax-function' is an obsolete variable (as
of Emacs 23.3); use `syntax-begin-function' instead.
I'm assuming the upstream authors will take care of these warnings in the future. Until then, how can I prevent these errors from appearing and opening a new window?
I'm currently back on 23.2 due to another issue, but I hacked a workaround for this issue while I was trying 23.3. It simply prevents the variable from being considered obsolete, but until Mumamo sorts itself out, that seemed preferable!
;; Mumamo is making emacs 23.3 freak out:
(when (and (equal emacs-major-version 23)
(equal emacs-minor-version 3))
(eval-after-load "bytecomp"
'(add-to-list 'byte-compile-not-obsolete-vars
'font-lock-beginning-of-syntax-function))
;; tramp-compat.el clobbers this variable!
(eval-after-load "tramp-compat"
'(add-to-list 'byte-compile-not-obsolete-vars
'font-lock-beginning-of-syntax-function)))
There are four levels of options for the warnings :
warning-minimum-level
warning-minimum-log-level
warning-suppress-types
warning-suppress-log-types
There are more information on the Emacs Manual.
I fixed it by running this on the elisp:
sed -i.bak 's/font-lock-beginning-of-syntax-function/syntax-begin-function/g' `find . -name '*.el' -exec grep -l 'font-lock-beginning-of-syntax-function' {} \;`
Phils's solution didn't work for me for some reason. Here's a more low-level way to do it.
(remprop 'flet 'byte-obsolete-info)
(remprop 'labels 'byte-obsolete-info)
Sometimes I need to read log files that have ^M (control-M) in the line endings. I can do a global replace to get rid of them, but then something more is logged to the log file and, of course, they all come back.
Setting Unix-style or dos-style end-of-line encoding doesn't seem to make much difference (but Unix-style is my default). I'm using the undecided-(unix|dos) coding system.
I'm on Windows, reading log files created by log4net (although log4net obviously isn't the only source of this annoyance).
(defun remove-dos-eol ()
"Do not show ^M in files containing mixed UNIX and DOS line endings."
(interactive)
(setq buffer-display-table (make-display-table))
(aset buffer-display-table ?\^M []))
Solution by Johan Bockgård. I found it here.
Modern versions of emacs know how to handle both UNIX and DOS line endings, so when ^M shows up in the file, it means that there's a mixture of both in the file. When there is such a mixture, emacs defaults to UNIX mode, so the ^Ms are visible. The real fix is to fix the program creating the file so that it uses consistent line-endings.
What about?
C-x RET c dos RET C-x C-f FILENAME RET
I made a file that has two lines, with the second having a carriage return. Emacs would open the file in Unix coding, and switching coding system does nothing. However, the universal-coding-system-argument above works.
I believe you can change the line coding system the file is using to the Unix format with
C-x RET f UNIX RET
If you do that, the mode line should change to add the word "(Unix)", and all those ^M's should go away.
If you'd like to view the log files and simply hide the ^M's rather than actually replace them you can use Drew Adam's highlight extension to do so.
You can either write elisp code or make a keyboard macro to do the following
select the whole buffer
hlt-highlight-regexp-region
C-q C-M
hlt-hide-default-face
This will first highlight the ^M's and then hide them. If you want them back use `hlt-show-default-face'
Edric's answer should get more attention. Johan Bockgård's solution does address the poster's complaint, insofar as it makes the ^M's invisible, but that just masks the underlying problem, and encourages further mixing of Unix and DOS line-endings.
The proper solution would be to do a global M-x replace-regexp to turn all line endings to DOS ones (or Unix, as the case may be). Then close and reopen the file (not sure if M-x revert-buffer would be enough) and the ^M's will either all be invisible, or all be gone.
You can change the display-table entry of the Control-M (^M) character, to make it displayable as whitespace or even disappear totally (vacuous). See the code in library pp-c-l.el (Pretty Control-L) for inspiration. It displays ^L chars in an arbitrary way.
Edited: Oops, I just noticed that #binOr already mentioned this method.
Put this in your .emacs:
(defun dos2unix ()
"Replace DOS eolns CR LF with Unix eolns CR"
(interactive)
(goto-char (point-min))
(while (search-forward "\r" nil t) (replace-match "")))
Now you can simply call dos2unix and remove all the ^M characters.
If you encounter ^Ms in received mail in Gnus, you can use W c (wash CRs), or
(setq gnus-treat-strip-cr t)
what about using dos2unix, unix2dos (now tofrodos)?
sudeepdino008's answer did not work for me (I could not comment on his answer, so I had to add my own answer.).
I was able to fix it using this code:
(defun dos2unix ()
"Replace DOS eolns CR LF with Unix eolns CR"
(interactive)
(goto-char (point-min))
(while (search-forward (string ?\C-m) nil t) (replace-match "")))
Like binOr said add this to your %APPDATA%.emacs.d\init.el on windows or where ever is your config.
;; Windows EOL
(defun hide-dos-eol ()
"Hide ^M in files containing mixed UNIX and DOS line endings."
(interactive)
(setq buffer-display-table (make-display-table))
(aset buffer-display-table ?\^M []))
(defun show-dos-eol ()
"Show ^M in files containing mixed UNIX and DOS line endings."
(interactive)
(setq buffer-display-table (make-display-table))
(aset buffer-display-table ?\^M ?\^M))
(add-hook 'text-mode-hook 'hide-dos-eol)
Is there a substitute in emacs for the vi "gf" command?
meaning try to open the file which is under the cursor right now
if a real file name is in fact there.
Thanks
You want the find-file-at-point function (which is also aliased to ffap). It's not bound to a key by default, but you can use
M-x ffap
Or, you can put in your .emacs file:
(ffap-bindings)
This will replace many of the normal find-file key bindings (like C-x C-f) with ffap-based versions. See the commentary in ffap.el for details.
Thanks, it works quite well but somehow the vi (gf) version is
still somewhat smarter. I think it looks at some path variable for search paths.
I made something which is needlessly complicated but works for me (only in linux).
It uses the "locate" command to search for the path under the cursor.
I guess it could be made smarter by searching the relative path to the current file first.
sorry for my bad elisp skills...It can probably be achieved in a much nicer way.
put in your .emacs, then use with M-x goto-file
(defun shell-command-to-string (command)
"Execute shell command COMMAND and return its output as a string."
(with-output-to-string
(with-current-buffer standard-output
(call-process shell-file-name nil t nil shell-command-switch command))))
(defun goto-file ()
"open file under cursor"
(interactive)
(find-file (shell-command-to-string (concat "locate " (current-word) "|head -c -1" )) ))