I have an error in my emac configuration that causes tramp to fail to work. How can i find out how it comes to be if:
With init.el fully commented error persists
With emacs invoked with -q flag (emacs -q) error persists.
With emacs invoked with -Q flag (emacs -Q) error is not observed.
I have no site-start.el, default.el or .emacs.el.
What can be done to figure out where the error comes from?
Here are some backtraces: backtrace 1, backtrace 2.
How i reproduce the problem: try to enter /sudo::/some/path after C-x C-f. Since using -Q flag gets rid of it, i believe some of the site packages are to blame.
How can i determine what brought the problem?
Related
I use Emacs for Clojure development. When I started Repl by cider-jack-in I got some error, but I can see only a few last lines in echo area. When I click on echo area It says that "Minibuffer window is not active". How can I retrieve the whole error message?
You can see all the messages from the echo area in the *Messages* buffer.
I'm on an arch system (3.17.6-1-ARCH), using emacs 24.4.1
When I run a print command in emacs i get this error:
Spooling... Done: /usr/bin/lp: Error - unknown option "J"
It seemes somewhere a "-J" is passed to lp, but I can't seem to figure out
where.
The command works in a terminal, like:
# lp fu.txt
Passing it a J flag reproduces the error:
# lp -J
lp: Error - unknown option "J".
google/ddg didn't spit out anything helpful about emacs and lp
regarding the matter.
I'm setting the printer command like this in my .emacs config:
(setq lpr-command "lp")
I tried giving it an empty lpr-switches variable, but I take
from the documentation, that it only appends the switches.
If you have some clue about a solution or a hint to the origin
of the problem, I would be grateful if you drop it.
Documentation for lpr-add-switches reads:
Non-nil means construct -T and -J options for the printer program.
These are made assuming that the program is lpr;
if you are using some other incompatible printer program,
this variable should be nil.
So (setq lpr-add-switches nil) should solve your problem.
I'm trying, for the first time, to access remote files via tramp from Emacs on Windows. I'm trying to open a remote directory via C-x C-f /plink:user#host:/. However, when Emacs gets to "Tramp: found remote shell prompt" in the minibuffer, it hangs. And not only does the minibuffer hang, but all of Emacs hangs, so that I have to kill it via task manager. This unfortunately means that I can't see any debug information for tramp, because it outputs to an Emacs buffer. How can I go about debugging this?
I'm running Windows 8.1, Emacs 24.3, and plink 0.63.
I ran into a very similar situation with tramp ssh, and I can't guess at what your particular problem is, but only that you can get a complete trace by doing:
(setq tramp-verbose 10)
Then try the connection again, and after it hangs, C-g and check for a buffer:
*debug tramp/plink USER#IP*
The level 10 verbosity might be too overwhelming - you can experiment with lesser levels (smaller numbers) to see if it reveals what the problem might be. Check the docstring for tramp-verbose.
Good Luck!
I have setup tramp mode with emacs, have been working using that mode for awhile, recently I start getting following error where I am unable to open any files.
Loading /etc/emacs/site-start.d/50sml-mode.el (source)...done [3 times]
For information about GNU Emacs and the GNU system, type C-h C-a.
Tramp: Opening connection for toolserver using scp...
Tramp: Sending command `exec ssh -e none toolserver'
Tramp: Waiting for prompts from remote shell
Tramp: Sending command `exec ssh -e none toolserver'
Tramp: Found remote shell prompt on `toolserver'
Tramp: Opening connection for toolserver using scp...done
byte-code: Couldn't find exit status of `test -e /home/FILE_NAME.py'
I have re-name the actual file to FILE_NAME.py
Actions taken:
I deleted the .tramp_history file but that didn't fix the problem.
try using the scpx or sshx protocol instead.
try (setq tramp-verbose 6) and check the output buffer to see what's really happening (C-h v tramp-verbose to see the levels), then proceed from there.
Sometimes, it's because my ssh-agent is dead. Restarting it solves the problem.
Sometimes it's because TRAMP still thinks the connection is somewhat usable when it's not. When this happen, I do M-x ibuffer * * D RET to kill all the TRAMP buffers so it starts over.
If none of this works, try to use latest TRAMP from melpa or to reinstall it. TRAMP works pretty fine out of the box, maybe you tweaked something that broke it?
I'm trying to get flymake to work, but when I run flymake-mode, I get the following error
switched OFF Flymake mode for buffer TdDisassemblerIde.cpp due to fatal status \
PROCERR, warning Failed to launch syntax check process 'make' with args (-s -C ./ \
CHK_SOURCES=TdDisassemblerIde_flymake.cpp SYNTAX_CHECK_MODE=1 check-syntax): Wrong type \
argument: symbolp, (utf-8)
Any clues?
When I have a problem with flymake, I do
M-x set-variable flymake-log-level <RET> 3
And then run flymake again (M-x flymake-mode).
Then look in the *Messages* buffer for a useful error message.
The last time this happened to me, about an hour ago, my check-syntax target in the flymakefile lacked a source module; I had added a module but had forgotten to add it to the list of files that should be included in a flymake compilation. Modifying the makefile corrected it. (This was for C#, but setting flymake-log-level should work to get a diagnosis for you too.)
Answering my own question: the problem was that I had set process-coding-system-alist to contain the symbol utf-8, and apparently flymake does not like that. Setting process-coding-system-alist to nil solved the problem.