Yes - packages have been in updates-testing for the past week. Please try those
packages and report any bugs. I'll push them to updates next week.

The table generation seems broken by default for emacs22 on fedora 7. I use the
below dirty workaround in .emacs to fix it:
(unintern #'replace-in-string)

It's the code in /usr/share/emacs/site-lisp/muse/muse.el(from 3.02.93)
...
   ((fboundp 'replace-in-string)
    (replace-in-string text regexp replacement literal))
...
cause this problem.

Could you give a recipe to reproduce what you see? 

I've updated muse from update-testing :
emacs-common-muse-3.03-2.fc7.noarch.rpm 
emacs-muse-el-3.03-2.fc7.noarch.rpm
emacs-muse-3.03-2.fc7.noarch.rpm

The table generation issue reproduce:
0. You have new version of color-theme.el youself.
1. C-x C-f ,a new file table.muse, now we should be in muse major mode
2. input these line to create a table :
3. C-x C-s ,save it
4. M-: eval a elisp one line :  (setq debug-on-error t),  to enable the debug
traceback for next exception.
5. C-c C-t , style input is "html", publish the muse file as html, got traceback:
Debugger entered--Lisp error: (wrong-number-of-arguments (lambda (target old
new) (replace-regexp-in-string old new target)) 4)
  replace-in-string("ch1" "\\`[[:blank:]]+\\|[[:blank:]]+\\'" "" nil)
  muse-replace-regexp-in-string("\\`[[:blank:]]+\\|[[:blank:]]+\\'" "" "ch1")
  muse-trim-whitespace("ch1")
  mapcar(muse-trim-whitespace ("ch1" "ch2" "ch3"))
  muse-publish-table-fields(1 29)
  muse-xml-markup-table(" class=\"muse-table\" border=\"2\" cellpadding=\"5\"")
  muse-html-markup-table()
  muse-publish-markup("table" ((1000 "\\(\\`\n+\\|\n+\\'\\)" 0 "") (1100
"[[:blank:]]+$" 0 "") (1200 "\\`#\\([a-zA-Z-]+\\)\\s-+\\(.+\\)\n+" 0 directive)
(1250 "^;\\(?:[[:blank:]]+\\(.+\\)\\|$\\|'\\)" 0 comment) (1300 muse-tag-regexp
0 tag) (1400 muse-explicit-link-regexp 0 muse-publish-mark-link) (1600
"\\(^\\|[-[[:blank:]<('`\"\n]\\)\\(=[^=[:blank:]\n]\\|_[^_[:blank:]\n]\\|\\*+[^*[:blank:]\n]\\)"
2 word) (1700 "^\\(\\*+\\)\\s-+" 0 heading) (1800 "\\.\\.\\.\\." 0 enddots)
(1850 "\\.\\.\\." 0 dots) (1900 "^----+" 0 rule) (1950 "~~" 0 no-break-space)
(2000 "^Footnotes:?\\s-*" 0 fn-sep) (2100 "\\[\\([1-9][0-9]*\\)\\]" 0 footnote)
(2200
"^[[:blank:]]*\\(\\([^\n[:blank:]].*?\\)?::\\(?:[[:blank:]]+\\|$\\)\\|[[:blank:]]-[[:blank:]]*\\|[[:blank:]][0-9]+\\.[[:blank:]]*\\)"
0 list) (2300
"[[:blank:]]*\\+\\(-*\\+\\)+[[:blank:]]*\n\\(\\(.*[[:blank:]]+\\(|+\\)\\(?:[[:blank:]]\\|$\\).*\n\\)+\\([[:blank:]]*\\+\\(-*\\+\\)+[[:blank:]]*\\)\\(\n\\|\\'\\)\\)+"
0 table-el) (2350
"\\(\\([[:blank:]]*\n\\)?\\(\\(?:.*[[:blank:]]+\\(|+\\)\\(?:[[:blank:]]\\|$\\).*\\|[[:blank:]]*|[-+]+|[[:blank:]]*\\)\\(?:\n\\|\\'\\)\\)\\)+"
0 table) (2400 "^\\([[:blank:]]+\\).+" 0 quote) (2500
"\\(^\\|[[:blank:]]*\\)--\\($\\|[[:blank:]]*\\)" 0 emdash) (2600 "^[[:blank:]]*>
" 0 verse) (2700 "^\\(\\W*\\)#\\(\\S-+\\)\\s-*" 0 anchor) (2900
muse-explicit-link-regexp 0 link) (3000 muse-url-regexp 0 url) (3100
muse-wiki-interwiki-regexp 0 link) (3200 muse-wiki-wikiword-regexp 0 link) (3250
muse-wiki-project-file-regexp 0 link) (3300 "''''" 0 "") (3500
"\\([^[]\\)[-a-zA-Z0-9._]+@\\([-a-zA-z0-9_]+\\.\\)+[a-zA-Z0-9]+" 0 email) (10000
"\\(\\(\n\\(?:[[:blank:]]*\n\\)*\\([[:blank:]]*\n\\)\\)\\|\\`\\s-*\\|\\s-*\\'\\)"
3 muse-html-markup-paragraph)))
  muse-publish-markup-region(1 36 "table" ("html" :suffix muse-html-extension
:regexps muse-html-markup-regexps :functions muse-html-markup-functions :strings
muse-html-markup-strings :tags muse-html-markup-tags :specials
muse-xml-decide-specials :before muse-html-prepare-buffer :before-end
muse-html-munge-buffer :after muse-html-finalize-buffer :header muse-html-header
:footer muse-html-footer :style-sheet muse-html-style-sheet :browser
muse-html-browse-file))
  muse-publish-markup-buffer("table" ("html" :suffix muse-html-extension
:regexps muse-html-markup-regexps :functions muse-html-markup-functions :strings
muse-html-markup-strings :tags muse-html-markup-tags :specials
muse-xml-decide-specials :before muse-html-prepare-buffer :before-end
muse-html-munge-buffer :after muse-html-finalize-buffer :header muse-html-header
:footer muse-html-footer :style-sheet muse-html-style-sheet :browser
muse-html-browse-file))
  muse-publish-file("/home/hellwolf/tmp/table.muse" ("html" :suffix
muse-html-extension :regexps muse-html-markup-regexps :functions
muse-html-markup-functions :strings muse-html-markup-strings :tags
muse-html-markup-tags :specials muse-xml-decide-specials :before
muse-html-prepare-buffer :before-end muse-html-munge-buffer :after
muse-html-finalize-buffer :header muse-html-header :footer muse-html-footer
:style-sheet muse-html-style-sheet :browser muse-html-browse-file) nil nil)
  muse-project-publish-this-file(nil)
  call-interactively(muse-project-publish-this-file)

It's a problem of /usr/share/emacs/site-lisp/muse/muse.el* (line 450)
(or a conflict with color-theme)?

replace-in-string is a Lisp function in
`/data/home/hellwolf/mydoc/prog/emacs.d/site/color-theme.el'.
(replace-in-string target old new)

as replace-regexp-in-string is a official function shipped with emacs, I think
the code of "replace-in-string" could be removed from here to avoid the
potential conflict.

Can you try and see if the problem goes away if you don't load color-theme.el?
emacs -q should stop your init file being loaded. Does the problem persist if
you rune emacs -q?

Will, I tried emacs -q and found a more critical problem, the muse-mode just
stalled whatever I input, I'm trying to figure out what the settings I
configured made it worked for me. Can you confirm that "the muse-mode just don't
work by default" ?

I got it.
You'll get stalled if you open a muse file when your muse-project-alist variable
is not set.

And the muse table generation works good if color-theme is not installed without
any hack. But I still think it's a bug of muse.

Yes, I see the same issue - starting emacs -q and entering muse-mode hangs
Emacs. Not good, will report this upstream.

As to the original problem - I am confused as to why you think this is a muse
bug and not a color-theme bug. If I understand your diagnosis correctly, the
problem arises due to the definition of replace-in-string in color-theme, which
conflicts with the function shipped with Emacs. That being the case, the problem
is with color-theme.el. Have I misunderstood?

Actually, regarding emacs hanging upon entering muse-mode, I think I have found
the issue.

Currently the muse mode init file doesn't require muse-project. Can you try the
following:

1) Start emacs -q
2) In the scratch buffer, enter (require 'muse-project)
3) Press C-x C-e at the end of this line - in the *messages* buffer you should
see "muse-project" appear
4) Open a new file with a .muse extension and confirm that muse-mode is started
for that buffer

This works for me - I'll build a new package which adds the necessary (require
'muse-project) to the init file this evening and push that to testing. If you
could confirm that it works for you, that would be helpful.

I don't see it works for me. I followed your step but emacs still hangs when
open a muse file without properly defining the muse-project-alist variable(at
list one muse project is needed)

And as to the problem of replace-in-string, in
/usr/share/emacs/site-lisp/muse/muse.el :
448   (cond
449    ((fboundp 'replace-in-string)
450     (replace-in-string text regexp replacement literal))
451    ((fboundp 'replace-regexp-in-string)
452     (replace-regexp-in-string regexp replacement text fixedcase literal))

That is to say, the author thinks there may be a 'replace-in-string defined
somewhere and it takes four arguments. But in fact, replace-in-string is not
defined in emacs22 and the replace-in-string defined in color-theme.el takes
only three arguments. Whatever if it's a problem _belongs_ to muse, but we may
inform the upstream that the code here is problematical.

OK, thanks, now I understand your point.

Also, actually, I still see Emacs hanging without a muse-project-alist defined.

Will report both issues to the developers, as I can't see an immediate fix.

OK, have worked with the upstream maintainer to remedy these two bugs. I ahve
built new packages which should hit updates-testing in the next day or two. In
the meantime, if you want to test them, they can be pulled directly from koji
(the package build system) here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=11067

emacs-common-muse-3.03-3.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

Seems everything's ok now. Thanks for your effort.

emacs-common-muse-3.03-3.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.