Errors in Emacs starting Repl - emacs

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.

Related

Emacs finding site package cofiguration error

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?

Why won't a new emacs window open in x11

When I type emacs & in X11, a new window doesn't open. Instead I just get the PID of the process. This illustrates what I mean.
bash-3.2$ emacs &
[1] 38624
Why is this happening and how can I get emacs to open in a separate window?
You can't start terminal Emacs as a background job -- it needs to interact with the terminal. Whenever a background job attempts to write to the tty, it is immediately stopped.
I would expect that your next input into the terminal would have resulted in a message similar to this?
[1]+ Stopped emacs
(which would have been useful).
You could then foreground the job with fg.
Running emacs & only makes any sense with GUI Emacs.

How can I write to standard output in Emacs

I am trying to debug an Emacs program performance wise. In particular, I suffer an extremely long startup time (~5' compared to ~1' for a bare Emacs) on a remote connection via WLAN, cellphone etc. In this context, any message written is no help, for the display is not refreshed at all.
What I would like to do is to write onto the "standard output" of the Linux process. I am aware of the --batch mode but this is no help to me because I want to use Emacs interactively.
So how can I write messages out to the Linux-standard output (as opposed to the Emacs standard output)?
You can output to standard error like this:
(print "hello world" #'external-debugging-output)
or
(princ "hello world" #'external-debugging-output)
This can buffer, so be careful.It's not possible to output to standard out at the moment. I'm going to add that, I think!
Start emacs as a daemon (emacs --daemon) and any messages during the start-up sequence will be sent to stdout or stderr, as described by lunaryorn.
Connect to the server with emacsclient
The simplest way to kill the server is M-x kill-emacs RET
For details see C-hig (emacs) Emacs Server RET
Works for me in centos 6.8 (GNU Emacs 23.1.1):
(append-to-file "here I come to save the day\n" nil "/dev/stdout")
Try also using "/dev/tty" in place of "/dev/stdout":
Unclear from question if you intend to redirect "emacs -nw" stdout to a file and monitor that file externally (then use "/dev/stdout"); or are ok with writing to "/dev/tty" thus polluting the self-same tty of the main "emacs -nw" display.
If starting a GUI version of emacs, in such a way it may lose attachment to originating tty, can abuse environment variables to communicate an originating shell's tty to elisp.
This works for me using Aquamacs in Mac OS X. Launching from a bash shell:
$ MY_TTY=$(tty) open /Applications/Aquamacs\ Emacs.app &
then in emacs:
(append-to-file "here I come to save the day\n" nil (getenv "MY_TTY"))

Emacs tramp hangs with "Tramp: found remote shell prompt"

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!

flymake fails with "Wrong type argument: symbolp, (utf-8)"

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.