[Date Prev][Date Next][Thread Prev][][Date Index][Thread Index]

Re: w3m freezes / 99% cpu?



Katsumi Yamaoka wrote:
In [emacs-w3m : No.09906] Katsumi Yamaoka wrote:

add a Lisp form like the following to your ~/.emacs-w3m.el file:
(add-to-list 'w3m-command-environment '("GC_NPROCS" . "1"))

The last resort is to put the following in your ~/.emacs file:
(eval-after-load "w3m"
'(add-to-list 'w3m-command-environment '("GC_NPROCS" . "1")))

Jan Rychter wrote to me that both the workarounds never solved the problem. It is because the w3m command is called without binding the environment variable "GC_NPROCS" to "1" while loading w3m.elc in order to determine the default values of the variables `w3m-type', `w3m-version', and `w3m-compile-options'.

Then I asked him to test the next one; to add the following form
to the ~/.emacs file (not the ~/.emacs-w3m.el file):

(let ((process-environment (copy-sequence process-environment)))
  (setenv "GC_NPROCS" "1")
  (load "w3m" nil t)
  (add-to-list 'w3m-command-environment '("GC_NPROCS" . "1")))

This aims to load w3m.elc, binding "GC_NPROCS" to "1", to determine
the default values of the variables that I mentioned above.  However,
Jan replied that it didn't do the trick, too.  I don't know why,
though.  Anyway, there seems currently no smart way to solve the
problem concerned with GC 7.0 on MacOS X.

P.S. How about this?

;; Add it to ~/.emacs (not ~/.emacs-w3m.el).
(setq w3m-command "~/bin/w3m")

Where "~/bin/w3m" is:
--8<---------------cut here---------------start------------->8---
#!/bin/sh
PATH=/opt/local/bin:${PATH}; export PATH
GC_NPROCS=1; export GC_NPROCS
if test -z "$*"; then
exec w3m
else
args='';
for i in $*; do
if test -z "$args"; then
args=\'$i\';
else
args="$args"' '\'$i\';
fi
done;
eval "exec w3m $args"
fi
--8<---------------cut here---------------end--------------->8---
Using a wrapper script like this works fine for me.

Since w3m is borked outside of emacs as well (i.e. for command line invocation), and most people seem to use MacPorts to install it, perhaps the logical solution is to add a patch to the port.

If I get time later today, I will try to create, test, and submit a patch to do this to the [MacPorts issue tracker][1], but this is going to be real late (like +12 hours), as I won't be able to touch this again until after work.

[1]: http://trac.macports.org/projects/macports/