When running bzr in the native OSX Terminal.app, I see the status as follows:
32376kB 2kB/s / Build phase:Adding file contents 1282/3629
When running start-process, however, I see no status being output to the buffer. The process is functioning properly, just with no visible output until the end -- two (2) lines only:
Created new stacked branch referring to bzr://bzr.savannah.gnu.org/emacs/trunk/.
Process bzr-process finished
Is there another listening function that Emacs offers that will capture the above-mentioned status output by bzr so that I can see the progress?
(start-process
"bzr-process"
"*bzr-output*"
"/macports/bin/bzr"
"branch"
"--stacked"
"bzr://bzr.savannah.gnu.org/emacs/trunk"
"/Users/HOME/Desktop/emacs-trunk")
Maybe you can get bzr to give you the on-the-fly status output by running the process in a tty rather than through a pipe. For that, just let-bind process-connection-type as in:
(let ((process-connection-type t))
(start-process ...))
But IIRC this value already defaults to t, so maybe the problem is elsewhere. Maybe bzr checks the $TERM to see if it can correctly update the output. So maybe you can try
(let ((process-environment (cons "TERM=xterm" process-environment)))
(start-process ...))
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.
Is there any way to have Emacs display everything that is happening when running term / eshell?
For example, when I try to build Emacs in the tmp directory, there should be a downloading message in the terminal window that tells me the status. However, nothing is displayed. I believe it might be silently doing the job, but I want to see what the normal terminal window application usually displays when running?
M-x eshell
$ cd /tmp
$ bzr branch --stacked bzr://bzr.savannah.gnu.org/emacs/trunk emacs-trunk
I'm not seeing the usual message: 6167kB 243kB/s | Finding revisions
This issue was resolved by #Stefan in a related thread: https://stackoverflow.com/a/23388276/2112489
(defun lawlist-eshell ()
(interactive)
(let ((process-environment (cons "TERM=xterm" process-environment)))
(eshell)))
How can I tell emacs not to pop up the *Shell Command Output* buffer when calling a shell command like this?
(shell-command MY_COMMAND)
Currently emacs splits the current window into two, showing the (mostly irrelevant) output buffer. To me it would be completely sufficient if I could look it up later if I feel like it.
Maybe using shell-command was the root of the problem. I think I found a solution with call-process which works, although there may be a more elegant way:
(call-process-shell-command
"cat ~/.emacs.d/init.el"
nil "*Shell Command Output*" t
)
shell-command takes an optional argument OUTPUT-BUFFER where you can specify the buffer to output to. If it is t (actually not a buffer-name and not nil) it will be output in the current buffer. So we wrap this into a with-temp-buffer and will never have to bother with it:
(with-temp-buffer
(shell-command "cat ~/.emacs.d/init.el" t))
In my experience, if the shell command itself produces no output, then the emacs *Shell Command Output* buffer won't pop open.
Therefore, to avoid the output buffer, silence the output of the command.
One easy way is:
add " > /dev/null 2>&1" to the end of any shell command.
(Caveat: I'm unsure if /dev/null exists on 100% of platforms where one can run emacs, but on every Linux distro it should be fine.)
If the call to elisp function shell-command is in an elisp script, then you could change this:
(shell-command cmd)
to this:
(shell-command (concat cmd " > /dev/null 2>&1"))
If you occasionally do want to monitor the output, then you could create one wrapper function that suppresses the output via /dev/null, and one wrapper function with no suppression, and toggle between them as you wish.
The above advice was tested on: GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2017-09-20 on lcy01-07, modified by Debian
This utility function might help. It returns the actual value of the shell command
(defun shell-command-as-string (cmd)
(with-temp-buffer
(shell-command-on-region (point-min) (point-max)
cmd t)
(buffer-string)))
What's even better, is to use
(shell-command (concat cmd " 1>&2") t t)
This way, the output is saved in the error buffer, should you want to look at it. But it does not pop up automatically.
I'm trying to feed flymake output from Haxe compiler, but I don't know how to tell it where the make file lives (ideally, I'd use nxml file instead). So far I have this in the Makefile:
BIN = ./bin
MAIN = com.wunderwafer.Main
SWF = wunderwafer.swf
SWFSETTINGS = -debug -swf-version 10 -swf-header 800:600:31
HFLAGS = -main $(MAIN) $(SWFSETTINGS) -cp ./src -swf $(BIN)/$(SWF)
HC = haxe
default: compile
compile: $(HC) $(HFLAGS)
clean:
$(RM) -r $(BIN)/*
.PHONY: check-syntax
check-syntax:
$(HC) $(HFLAGS)
If I run it later like so:
$ make -k check-syntax
It produces the expected output. However flymake isn't able to find the Makefile (or so it seems) because the files I'm trying to check are deeper inside the src directory.
What is the way to configure flymake so it knows where the makefile is? (or, even better, just execute a shell command, because the common way to compile Haxe code is by using *.nxml settings file.
EDIT:
It looks like I'm getting closer, lots of thanks, but flymake is doing something strange, and I can't understand what exactly it does, so, here's the log:
received 65 byte(s) of output from process 967
file /home/wvxvw/projects/wafer/src/com/wunderwafer/map/Battlefield.hx, init=haxe-flymake-init
parsed 'Error : Invalid class name /home/wvxvw/projects/wafer/build.nxml', no line-err-info
file /home/wvxvw/projects/wafer/src/com/wunderwafer/map/Battlefield.hx, init=haxe-flymake-init
process 967 exited with code 1
cleaning up using haxe-flymake-cleanup
deleted file /tmp/flymake-Battlefield-855Cad.hx
Battlefield.hx: 0 error(s), 0 warning(s) in 0.15 second(s)
switched OFF Flymake mode for buffer Battlefield.hx due to fatal status CFGERR, warning Configuration error has occurred while running (haxe /home/wvxvw/projects/wafer/build.nxml)
The command I'm trying to make it run looks like this:
(defun haxe-flymake-get-cmdline (source base-dir)
"Gets the cmd line for running a flymake session in a Haxe buffer.
This gets called by flymake itself. The output is a list of two elements:
the command to run, and a list of arguments. The resulting command is like:
$ haxe ${project-root}/build.nxml
"
(message "base-dir %s" (file-name-as-directory base-dir))
(list *haxe-compiler*
(list
(concat (file-name-as-directory base-dir)
*build-nxml*))))
The message printed looks like this:
base-dir /home/wvxvw/projects/wafer/
So, as far as I could understand, the resulting command should be:
haxe /home/wvxvw/projects/wafer/build.nxml
But it looks like flymake either adds something in front of the argument or afterwards, which makes Haxe compiler generate the error "Error : Invalid class name" - this error would be given if there was one extra argument, which the compiler would have understood as an extra class to compile. But the log doesn't show what is being sent...
EDIT 2:
I've added:
#!/usr/bin/env bash
echo "$#" > /home/wvxvw/projects/wafer/log
And made flymake invoke this script instead of the compiler, and it passes only one argument, just as I would expect it... sigh
It's a good question. I don't know a simple way of adding in a new "flavor" of make tool into flymake. I know of a way, it's just not simple. This is what I did for php codesniffer - it will be similar for any arbitrary make tool.
First, define an install fn.
(defun fly/phpcs-install ()
"install flymake stuff for PHP CodeSniffer files."
(add-to-list
'flymake-err-line-patterns
(list fly/phpcs-error-pattern 1 2 3 4))
(let* ((key "\\.php\\'")
(phpentry (assoc key flymake-allowed-file-name-masks)))
(if phpentry
(setcdr phpentry '(fly/phpcs-init fly/phpcs-cleanup))
(add-to-list
'flymake-allowed-file-name-masks
(list key 'fly/phpcs-init 'fly/phpcs-cleanup)))))
This installs a new entry into the flymake alist, keyed on .php as a file extension. The entry in flymake's list basically relates the file extension to a pair of functions, one for init and one for cleanup.
The init fn simply returns the command to run to check syntax. This can be a shell command, with the appropriate arguments. For codesniffer this fn looks like this:
(defun fly/phpcs-init ()
"initialize flymake for PHP using the PHP CodeSniffer tool."
(let ((create-temp-f 'fly/phpcs-create-temp-intemp)
(use-relative-base-dir t)
(use-relative-source t)
(get-cmdline-f 'fly/phpcs-get-cmdline)
args
temp-source-file-name)
(setq temp-source-file-name (flymake-init-create-temp-buffer-copy create-temp-f)
args (flymake-get-syntax-check-program-args
temp-source-file-name "."
use-relative-base-dir use-relative-source
get-cmdline-f))
args))
Yikes! Down the rabbit hole we go. The get-cmdline fn looks like this:
(defun fly/phpcs-get-cmdline (source base-dir)
"Gets the cmd line for running a flymake session in a PHP buffer.
This gets called by flymake itself. The output is a list of two elements:
the command to run, and a list of arguments. The resulting command is like:
php.exe -d auto_append_file="" -d auto_prepend_file="" phpcs\scripts\phpcs --report=emacs file.php
"
(list fly/phpcs-phpexe
(list
"-d" "auto_append_file=''"
"-d" "auto_prepend_file=''"
(concat (file-name-as-directory fly/phpcs-phpcs-dir)
"scripts\\phpcs")
(concat "--standard=" fly/phpcs-standard)
"--report=emacs"
"-s" ;; show the fullname of the rule being violated
(expand-file-name source))))
You can see the full elisp at http://www.emacswiki.org/emacs/flyphpcs.el
There's probably a simpler way. I just don't know it.
If I am trying to run a shell-command in an Emacs Lisp function in which I call rsync (or scp) multiple times, which shell-command variant should I use? I am currently using shell-command, which locks up Emacs until the process is done, and the output that should be visible with the --verbose to rsync is not printed; I can use shell-command with an & at the end of the command string to make it asynchronous, which does print the progress — but while it doesn't "lock up" Emacs entirely, the minibuffer repeatedly asks if I want to kill the process which is crippling in the meantime; and start-process-shell-command, which appears to halt the function only after the first file/directory is transferred; neglecting the rest when there are multiple rsync calls made through my function. None of these seem ideal, any hints?
I have had the most success using start-process myself.
(start-process "process-name"
(get-buffer-create "*rsync-buffer*")
"/path/to/rsync"
arg1
...
argn)
This will send all the output to a single buffer.
One solution might be to run the command in an actual shell buffer. Then you get to choose which one of those to run:
M-x shell
M-x eshell
M-x term
If you like that idea, you can code it up like this:
(defun my-rsync-routine ()
"run some rsync processes"
(with-temp-buffer
(shell (current-buffer))
(process-send-string nil "rsync ...")
(process-send-string nil "rsync ...")
(process-send-string nil "rsync ...")))
Read more on 'process-send-string for its usage. You might also want to have some error checking on the output from the processes.