本手册针对 Emacs Muse 3.02.92 (3.03 RC2) 版本。
Copyright © 2004, 2005, 2006 Free Software Foundation, Inc.
基于 GNU 通用公共许可证(General Public Licese)的条款 任何人有权复制,发布和/或修改本文档。[翻译]:郑海永(Haiyong Zheng) zhyfly.org@gmail.com http://www.zhyfly.org
--- 详细节点列表 ---
怎样获得 Muse 发行及开发更新
使用标记的规则
发布不同类型的文档
集成 Muse 和 pyblosxom.cgi
制作你自己的发布风格
风格共有的通用功能
本文档描述了 Muse,它由 John Wiegley 所写,现在由 Michael Olson 维护。 本文档有下面几种在线版本可用。
Emacs Muse 是一个基于 Emacs 的写作和发布平台。它简化了文档编辑过程, 并且可以选择多种格式进行发布。
Muse 包括两个主要部分: 一个增强的 text 模式,用来编辑文档和在 Muse 工程中随意浏览文档; 一组发布策略,用来产生各种不同的格式输出。
然而这种思想并不新颖,有大量类似的系统存在 ── 甚至 Emacs 本身就有另外一个 (Bhl Mode)。Muse 所增色的地方是一个更加模块化的平台,带有一个相当简单的核心, 在这个平台上“风格”可被派生而生成新的风格。Muse 全部的功能中大部分是可选的。 比如,你可以不在 major-mode 下使用发布功能,或者在 major-mode 下但不做任何发布; 又或者如果你不加载 Texinfo 或 LaTeX 模块,那么相应的那些风格就不可用。
Muse 代码基于 emacs-wiki.el 版本 2.44,但代码已经重新组织和改写,特别是那些发布 函数。此次修订的重点在写作和发布方面,Wiki 部分作为其中一个默认的行为 (在可选的 muse-wiki 模式中)。在默认情况下 CamelCase 词组(每个单词的 第一个字母都大写,其它小写)不再特殊对待。
如果你想承担最小的风险,那么选择安装一个发行版。
错误被首先在开发中更正。用户可见的修正将公布在 muse-el-discuss@gna.org 邮件列表中。See Getting Help and Reporting Bugs。
Debian 和 Ubuntu 用户可以通过 apt-get 获得 Muse。muse-el 包在
Michael Olson 的 APT 仓库及官方 Debian 和 Ubuntu 仓库都可用。要使用
Michael Olson 的 APT 仓库,添加下面一行到你的 /etc/apt/sources.list
文件并运行 apt-get install muse。
deb http://www.mwolson.org/debian/ ./
另外,你也可以从 http://www.mwolson.org/static/dist/muse/ 下载最新的发行版。
如果你想要追求 Muse 开发的最新技术或者在发行前尝试新特色,那么选择开发版本。
Arch 修正控制系统允许你找回以前的版本,从而选择某些指定的特色和 bug 修复。 如果你想帮助 Muse 开发,强烈推荐使用 Arch,但这并不是一个必要条件。
如果 Arch 对你来说是陌生的,你可能会认为下面这篇手册很有帮助: http://www.mwolson.org/projects/ArchTutorial.html。
使用 Arch 下载 Muse 模块,并参照下面步骤保持最新。
tla register-archive -f http://www.mwolson.org/archives/2005
# 下载 Muse 到 muse 目录。
tla get mwolson@gnu.org--2005/muse--main--1.0 muse
# 进入你关心的源目录。
cd muse/
# 显示更改概要。
tla missing --summary
cd muse
tla replay
与 Muse 归档交互还有一些其他的方法。
最新开发快照与 Arch 存储库同时被更新,因此它始终保持最新。
Muse 可以在你的机器上被编译并安装。
这是一个可选的步骤,因为 Emacs Lisp 源代码没有必要必须进行字节编译。 但这样做可以产生速度的提升。
为了编译 Emacs Muse,一个Emacs 或 XEmacs 的工作副本是必须的。 默认情况下,安装时命名为 emacs 的程序将被使用。
如果你想要使用二进制文件 xemacs 来执行编译,你需要象下面这样编辑 顶层目录中的 Makefile.defs 文件。你可以输入 Emacs 或者 XEmacs 二进制文件 所在的全路径,或者只要其全路径在环境变量 PATH 中就可以仅仅输入命令名。
EMACS = xemacs
SITEFLAG = -no-site-file
运行 make 就会编译 lisp 目录中的 Muse 源文件。
通过下述操作 Muse 可以被安装到你的文件层次结构中。
编辑 Makefile.defs 文件使得 ELISPDIR 指向你想要的 Muse 源文件 和编译文件的安装路径, INFODIR 表示 Muse 手册的安装路径。当然, 如果你使用 XEmacs 你需要如编译部分所说的那样编辑 EMACS 和 SITEFLAG。
如果你在一个 Debian 或者 Ubuntu 系统中安装 Muse,你可能需要按照文件 Makefile.defs 中的说明更改变量 INSTALLINFO 的值。
如果你想要安装 Muse 到一个非默认指定的位置,那么如前所说,编辑 Makefile.defs 文件。
然后以普通用户身份运行 make。
如果你选择的安装位置要求必须 root 用户,那么以 root 身份运行
make install。
要使用 Muse,添加包含 Muse 文件的目录到你的 load-path 变量中,
它一般在你的 .emacs 文件中定义。然后,加载写作模式和你想要发布的
文档风格。下面是一个例子。
(add-to-list 'load-path "<path to Muse>")
(require 'muse-mode) ; load authoring mode
(require 'muse-html) ; load publishing styles I use
(require 'muse-latex)
(require 'muse-texinfo)
(require 'muse-docbook)
一旦 Muse 模式被加载,命令 M-x muse-publish-this-file 将发布一个 输入文档为任意可用的风格。如果你想在一个 buffer 中启用 muse-mode, 那么输入 M-x muse-mode,它被绑定到 C-c C-t。
如果当前打开的文件属于 muse-project-alist 中一个定义的项目,
那么可以使用 C-c C-p 来发布它。
你也可以输入 M-x customize-group,然后给出名 `muse'。每一个选项 都有它自己的文档。
通常你希望自动将一个目录中的所有文件发布为一组特定的输出风格,为此, Muse 允许创建“项目”。下面是一个定义在你的 .emacs 文件中的项目范例。
(require 'muse-project)
(setq muse-project-alist
'(("website" ; my various writings
("~/Pages" :default "index")
(:base "html" :path "~/public_html")
(:base "pdf" :path "~/public_html/pdf"))))
上面定义了一个名为“website”的项目,该项目所有的文件都位于目录 ~/Pages 下,默认的访问页为 index。当该项目被发布时,每一页 将会以 HTML 格式输出到 ~/public_html 目录中,并以 PDF 格式输出到 ~/public_html/pdf 目录中。在项目中的任一页中,你可以使用语法 `[[pagename]]' 创建到其他页的链接。
默认情况下 Muse 要求所有的项目文件具有扩展名 .muse,不具有这个扩展名 的文件将不会被关联到 Muse 模式,也将不会被看作任何项目的一部分,即使这些 文件确确实实在一个项目目录中。
如果你不想使用扩展名 .muse,你可以通过设置 muse-file-extension
的值来自定义扩展名。
如果你不想使用任何扩展名,而是想要 Muse 基于项目文件位置自动探测项目文件, 那么在你的 Muse 设置文件中加入下面两行。
(setq muse-file-extension nil
muse-mode-auto-p t)
如果你想要仅仅包括一个目录中的几个文件,那么你需要使用一个正则表达式代替 例子中的 ~/Pages。
一个 Muse 文档使用特别的、文脉上的标记规则来决定怎样格式化输出结果。例如, 如果一个段落被缩进了,Muse 就认为它应该被引用。
并没有太多的标记规则,而且所有的标记规则力争简单以便让使用者更加专注于 文档创作,而不是格式。
以六个或者更多的空白字元(Tab 或者空格)开始的一行表示一个居中的段落。 另外,你也可以使用 <center> 标签使得其包含的区域被发布为居中的段落。
但是如果一行以空白字元开始,但空白字元不足六个,这表示一个引用的段落。 另外,你也可以使用 <quote> 标签使得起包含的区域被发布为引用的段落。
<example> 标签用于示例,其中空白应该被保留,等宽间距文本,且输出 风格的任意特殊字符都被转义。
还有一个 <literal> 标签,作用是使得所标记的块全部原样输出。比如 这可以用来插入一段手编的 HTML 代码到 HTML 输出。
依赖于输出风格一个标题会成为打印输出的一章或者一节。以一个或几个星号开始 一个新的段落,后面跟一个空格和标题题目,来表示一个标题。然后另起一段输入 这部分的正文。
所有层次的标题都将会被发布,然而,大部分发布风格仅仅会区分头四个层次。
* First level
** Second level
*** Third level
**** Fourth level
文档中全部的段落或者区段前以 `#' 开始的行是指令。指令的格式为 “#directive content of directive”。你可以使用任意大小写字母的组合作为指令, 即使它没有在下面列出。
muse-publishing-directive 函数可以被用于页眉和页脚来存取指令。例如,
使用 (muse-publishing-directive "title") 来存取 `#title' 指令。
#author如果它没有被指定,Muse 将试图从变量 user-full-name 来推断它。
#date它由那些能够嵌入日期信息的发布风格使用。
#desc它被 journal 发布风格用来在一个 RSS/RDF 源内部嵌入信息。
#title如果它没有被指定,那么将使用文件名作为文档题目。
*emphasis*
**strong emphasis**
***very strong emphasis***
_underlined_
=verbatim and monospace=
当在 Muse 模式下编辑一个 Muse 文档时,这些强调形式将会以一种所见即所得 (WYSIWYG)的方式高亮显示。每种形式可跨越多行。
抄录(verbatim)文本默认情况下被灰色显示,定制 muse-verbatim-face
来改变它。
你也可以使用 <code> 标签来表示抄录(verbatim)和等宽(monospace) 文本,这在本身含有“=”的区域中很方便。
一个脚注引用就是简单的一个在方括号中的数字,在你的文件底部放置脚注的注解 来定义它。`footnote-mode' 可以被用来非常方便的生成这种脚注。
脚注由行首方括号内的相同数字所定义,在输入的时候使用 footnote-mode 的 C-c ! a 命令会很容易的插入脚注,使用 C-x C-x 便返回插入点。
诗要求空白字元被保留,但不采取等宽。为显示诗使用下面的标签,它让我们想起 email 引用的方式。
> A line of Emacs verse;
> forgive its being so terse.
你也可以使用 <verse> 标签,如果你喜欢。
<verse>
A line of Emacs verse;
forgive its being so terse.
</verse>
<verse>
A line of Emacs verse;
forgive its being so terse.
In terms of terse verse,
you could do worse.
</verse>
列表是由行首使用的特殊字符产生,在符号列表项或数字列表项前必须有一个空白字元用于 区别那些字符可能确实出现在一个句子中的情况。
- bullet item one
- bullet item two
1. Enum item one
2. Enum item two
Term1 ::
This is a first definition
And it has two lines;
no, make that three.
Term2 ::
This is a second definition
Double bars || Separate header fields
Single bars | Separate body fields
Here are more | body fields
Triple bars ||| Separate footer fields
一些发布风格要求首先是表头,紧跟着是表底,然后才是表体。你可以对这些部分 使用你喜欢的任意顺序,Muse 在发布时将会为你重新排序。
如果你想禁用一个 Muse 文件的表格生成,添加指令 `#disable-tables t' 到文件的顶部。
一个超级链接可以引用一个 URL或者某个 Muse 项目中的其他页面。另外,描述文本 可以被指定并在支持链接描述的输出风格中显示,而不是显示链接文本。
[[link target][link description]]
[[link target without description]]
因而,当前 Muse 维护者的主页可以从 `[[http://www.mwolson.org/projects/EmacsMuse.html][here]]', 或者 `[[http://www.mwolson.org/projects/EmacsMuse.html]]' 找到。
输入文本中的一个 URL 或者 email 地址被发布为一个超链接,这种链接被称做 implicit links,因为不管怎样它们与 Muse 文档的其他部分没有分离。
URL 中的一些字符会禁止 Muse 把它们当作 implicit links,如果你想要链接一个 包含空格或者“][,"'`()<>^”中任一个字符的 URL,那么你必须使用 explicit links, 当“.,;:”这些标点符号出现在一个 URL 的末尾时它们也不会被看做是这个 URL 的 一部分。关于如何写一个 explicit link 参见 Hyperlinks and email addresses with descriptions。
如果 muse-wiki 模块被加载,另一种 implicit link 的形式就可用了。 以 CamelCase 形式输入的 Wikinames 被高亮显示并发布为链接,这提供给该文件 一种引用其他存在文件的方式。
通过编辑 muse-wiki-wikiword-regexp 选项接着运行
(muse-configure-highlighting 'muse-colors-markupmuse-colors-markup)
就可以完成 WikiName 认可定制。如果你使用定制界面,后面的部分会自动完成。
muse-wiki 模式也允许 InterWiki links,这与 WikiWords 很相似,
但 InterWiki links 不但可以指定某个项目,而且也可以指定某个文件页面。
默认情况下在 muse-project-alist 中定义的项目条目名将被用于 InterWiki 名。
下面是几个例子。
Blog::DocumentingMuse
Projects#EmacsMuse
Website
第一种情况,interwiki 分隔符是 `::',`Blog' 为项目名, `DocumentingMuse' 为页面名;第二种情况,`#' 是 interwiki 分隔符。象第三种情况这样,如果一个项目名单独出现在文本中, 那么它会被加色并发布为一个指向该工程默认页面的一个链接。
通过编辑 muse-wiki-interwiki-alist 选项可以完成 interwiki links
的定制。
指向图片的链接可以被用于目标或者描述中,也可以两者都使用。所以,下面的 代码会发布一个指向 http://www.mwolson.org/ 可点击的图片。
[[http://www.mwolson.org/][/static/logos/site-logo.png]]
如果在链接描述中遇到一个指向本地可用图片的链接,并且你的 Emacs 版本允许 图片显示,那么 Muse 模式会试图显示它。
这个行为可以由 C-c C-i 触发,或者通过设置选项
muse-colors-inline-images 为 nil 来永久禁止此功能。
通过定制 muse-colors-inline-image-method 选项可以 Muse 改变查找图片
的方式。这个选项的一个有用的值为 muse-colors-use-publishing-directory,
它告诉 Muse 模式去查找当前文件将要被发布的目录。默认情况下是在当前目录下
查找。对于任一设置类似 `../pic/' 这样的相对路径应该是有效的。
最后,我们希望通过定制 muse-project-alist Muse 能够从一个“源”目录
复制图片到一个发布目录中,但这个功能尚未完成。
如果在 ../pics/ 目录中存在一个叫做 TestLogo.png 的文件,那么 下面的这个例子将会正确显示和发布。如果文本与图片在同一行,那么在输出 中也是如此。
[[../myimage.png]]
如果你想要为一幅图片添加标题,使用下面的语法。它将图片居中(如果所发布的 格式支持该功能)并在图片下面添加一个居中的标题。对于那些不支持图片居中的 格式将以图片紧靠左边界来代替。
[[../pics/mycat.png][My cat Dexter]]
带有标题的图片仅可以自成一段,在同一行不允许有文本。否则,发布的输出句法 上是错误的。
四个或者更多的破折号(-)表示一个水平线。确保其前后都是空行,否则它将被 看作是前面或后面段落的一部分。
如果你以“#anchor”开始一行 ── 其中“anchor”可以是任意不包含空白字元的 单词 ── 那么它在所在位置定义了一个进入文档内部的锚。在一个 Muse 链接中 使用“page#anchor”作为目标就可以引用这个锚点。
使用 <lisp> 标签可以得到任意种类的标记,它也是仅有的在一个风格的页眉 和页脚文本中支持的 Muse 标签。使用 <lisp> 标签你可以生成任意你想要的输出。 如果 <lisp> 标签出现在文档正文内部,那么插入的输出将会被标记出。
<lisp>(concat "This form gets " "inserted")</lisp>
注意不能在一组 <lisp> 标签中使用 insert 命令,因为这样的话
<lisp> 标签的返回值将被自动插入文档中。
; Comment text goes here.
也就是说,仅仅行首一个分号,紧跟一个文字空白,就使得这一行被当作注释了。
在发布过程中 Muse 有几个内嵌标签证明非常有用。See muse-publish-markup-tags 来了解怎样定制 Muse 使用的标签和怎样制作你自己的标签。
如果一个标签带有参数,那么它就会看起来象下面这样,其中“tagname”是标签名。
<tagname arg1="string1" arg2="string2">
如果你想要一个标签看起来更象来自一个标准的 XHTML 文档,作为选择你可以照 下面这样做。
<tagname arg1="string1" arg2="string2" />
如果一个标签包围一些文本,那么它看起来象下面这样。
<tagname>Some text</tagname>
如果一个标签包围一大块区域,那么它看起来象下面这样。
<tagname>
Some text.
Some more text.
</tagname>
下面是 Muse 所采用的完整的标签列表,其中包括前面章节中所提到的那些标签。
如果发布成其他的格式,那么对文本没有任何作用。
“markup”参数控制这块区域是怎样被标记。
如果它被省略,那么使用正常的 Muse 规则发布这个区域。
如果是“nil”,那么根本不标记这个区域,但也禁止 Muse 进一步解释它。
如果是“example”,那么这个区域就象被 <example> 标签包围那样被处理。
如果是“verse”,那么这个区域就象被 <verse> 标签包围那样被处理, 保留其中的新行。
否则,它应是要调用的一个函数名,带有一个被限定在这个区域的 buffer。
默认情况下生成的目录中仅仅包含一级和二级标题。定制 muse-publish-contents-depth
选项来全局地改变它。要想仅仅为当前这个标签改变,使用“depth”参数。
<include file="included_file">
“markup”参数控制这块区域是怎样被标记。
如果它被省略,那么使用正常的 Muse 规则发布被包括的文本。
如果是“nil”,那么根本不标记被包括的文本。
如果是“example”,那么被包括的文本就象被 <example> 标签包围那样 被处理。
如果是“verse”,那么被包括的文本就象被 <verse> 标签包围那样被处理, 保留其中的新行。
否则,它应是插入文件后要调用的一个函数名,带有一个被限定在被插入区域的 buffer。
insert。结果文本中的所有文本属性被去掉。
这个标签带有“markup”参数,参见 <command> 的描述查看细节。
这在页眉和页脚中标记区域时非常有用。记忆中的一个例子就是通过下面的操作生成 一个当前项目下的所有文件的发布索引。
<markup><lisp>(muse-index-as-string t t)</lisp></markup>
这个标签带有“markup”参数,参见 <command> 的描述查看细节。
这个标签带有“markup”参数,参见 <command> 的描述查看细节。
这个标签带有“markup”参数,参见 <command> 的描述查看细节。
在前面的 Muse 版本中这个标签使用很频繁因为那些版本不支持整个文档的特殊转义。
现在,这个标签仅仅为其他标签需要,或许在脚注中需要。
Muse 的一个基本特色是它能够把一个简单的输入文本发布成种种不同风格的输出。 Muse 也使得创建一个新的风格或者从一个存在的风格中派生新风格变得容易。
Blosxom 发布格式发布一个归类文件树为一个文章的镜像树,并由 blosxom.cgi 或 pyblosxom.cgi 提供服务。换句话说,每个 blog 条目与一个文件相对应。
你需要在一个你具有上传访问权限的机器上安装 pyblosxom.cgi 或 blosxom.cgi。
为了使得 blog 条目的日期能够合理的显示,下面这些额外的组件是必须的。
在 contrib/pyblosxom 子目录中为 pyblosxom.cgi 提供这两个组件。 getstamps.py 提供前面的服务,而 hardcodedates.py 提供后面的服务。 最后期望找出或写出一个 blosxom.cgi 插件和脚本。
下面是在我的 timestamps 文件中的一个例子列表,其中每个文件与一个 日期相对应。其实这可以是任意格式,只要你的日期聚合脚本和插件都能够解析。
2005-04-01-14-16 personal/paper_cranes
2005-03-21 personal/spring_break_over
2004-10-24 personal/finished_free_culture
contrib/pyblosxom/make-blog 脚本示范了怎样调用 getstamps.py。 注意你需要设置当前目录为你的 Muse 文件所在的目录,执行 gestamps.py, 然后移动生成的时间戳文件到你的发布目录中。
每一个 Blosxom 文件必须包含 `#date yyyy-mm-dd' 或者可选的长格式 `#date yyyy-mm-dd-hh-mm',一个题目(使用 #title 指令)加上任意内容的正文。
日期指令不会直接由 pyblosxom.cgi 或者这个程序所使用。你需要有 上一节中提到的那两个额外组件来使用这个特色。
有一个名为 muse-blosxom-new-entry 的函数可以使得生成一个新的 blog 条目
的过程自动化。照下面所做来使用它。
muse-blosxom-base-directory 为你的 blog 条目存储的位置。
muse-blosxom-new-entry 函数到一个键序列。我使用下面的代码绑定这个
函数到 C-c p l'。
(global-set-key "\C-cpl" 'muse-blosxom-new-entry)
在 Blosxom 发布风格中下面的风格和选项可用。
muse-blosxom-extensionmuse-blosxom-header这可以是文本或者一个文件名。
muse-blosxom-footer这可以是文本或者一个文件名。
muse-blosxom-base-directorymuse-blosxom-new-entry 使用。
这是你的 blog 条目本地能找到的顶层目录。
这个发布风格被用于输出 LaTeX 或者 PDF 格式的“书”。
如果不使用关键字 :nochapters 每一个页面将会成为书中一个独立的章, 否则,它们就会象庞大的一章那样在一起。
为发布这种风格你需要调用 muse-book-publish-project 函数。在 John Wiegley
的配置文件 examples/johnw/muse-johnw.el 中可以找到这样的一个例子。
muse-book-before-publish-hookmuse-book-after-publish-hookmuse-book-latex-header这可以是文本或者一个文件名。
muse-book-latex-footer这可以是文本或者一个文件名。
这种发布风格被用于生成 DocBook XML 文件。
docbookmuse-docbook-extensionmuse-docbook-header这可以是文本或者一个文件名。
muse-docbook-footer这可以是文本或者一个文件名。
muse-docbook-markup-regexpsmuse-docbook-markup-functionsmuse-docbook-markup-strings这些字符串涵盖最基本的标记类,它们在各种风格之间的操作差别很小。
muse-docbook-markup-specialsmuse-docbook-encoding-defaultmuse-docbook-charset-defaultmuse-docbook-encoding-map 中如果没有找到转换,使用默认的 DocBook XML
字符集。
muse-docbook-encoding-map这种发布风格能够生成 HTML 或 XHTML 文档。
htmlxhtml如果一个 HTML 选项没有一个相应的 XHTML 选项,它将被用于这两种发布风格。
muse-html-extensionmuse-xhtml-extensionmuse-html-style-sheet这被用于 muse-html-header。你可以在这里放置原始的 CSS 或者放置一个
<link> 标签链接到一个外部的样式表。文本中可以包含 <lisp>
标记的标签。
如果你使用 XHTML,确保适当地关闭了 <link> 标签。
muse-html-header这可以是文本或者一个文件名。
muse-html-footer这可以是文本或者一个文件名。
muse-xhtml-header这可以是文本或者一个文件名。
muse-xhtml-footer这可以是文本或者一个文件名。
muse-html-anchor-on-word这允许你在一个浏览器中选择它们(比如,for pasting),但如果你的页眉风格和
你的链接风格不同就会产生以多种颜色标记页眉的副面效果。
muse-html-table-attributes如果你想要在 HTML 中制作更加复杂的表格,用 literal 标签包围 HTML
代码,这样它们就不会被转义。
muse-html-markup-regexpsmuse-html-markup-functionsmuse-html-markup-strings这些字符串涵盖最基本的标记类,它们在各种风格之间的操作差别很小。
muse-xhtml-markup-strings这些字符串涵盖最基本的标记类,它们在各种风格之间的操作差别很小。
muse-html-markup-tagsmuse-html-markup-specialsmuse-html-meta-http-equivmuse-html-meta-content-type如果你正在努力遵守 XHTML 1.1 标准,修改这个选项为 “application/xhtml+xml”。
muse-html-meta-content-encoding如果设置该选项为符号 'detect,就使用 muse-html-encoding-map 从 emacs 的
编码中试图并决定 HTML 的字符集;如果设置该选项为一个字符串,就会强制使用
这个字符串作为特定的字符集。
muse-html-charset-defaultmuse-html-encoding-map 中没有找到转换,使用默认的 HTML meta 字符。
muse-html-encoding-defaultmuse-html-encoding-map这个模块便于日志的撰写和发布,当发布成 HTML 时,它假定以网络日志或者博客 的形式发布。
下面是每一个条目的输入格式。
* 20040317: Title of entry
text for the entry.
<qotd>
"You know who you are. It comes down to a simple gut check: You
either love what you do or you don't. Period." -- P. Bronson
</qotd>
“quod”部分或者说当天的引述,完全是可选的。生成 HTML 后这个条目会产生 下面的输出。
<div class="entry">
<div class="entry-qotd">
<h3>Quote of the Day:</h3>
<p>"You know who you are. It comes down to a simple gut
check: You either love what you do or you don't. Period."
-- P. Bronson</p>
</div>
<div class="entry-body">
<div class="entry-head">
<div class="entry-date">
<span class="date">March 17, 2004</span>
</div>
<div class="entry-title">
<h2>Title of entry</h2>
</div>
</div>
<div class="entry-text">
<p>Text for the entry.</p>
</div>
</div>
</div>
大量的“div”标签使得以任意你想要的形式显示条目成为可能,这使用了一个 CSS 设计。
而且,通过发布你的日志为“.rdf”风格,一个 .RDF 文件就可以被生成。它使用 每个条目的第一段的前两句话作为它的“描述”,并自动生成链接到各个条目的 标签。
journal-htmljournal-xhtmljournal-latexjournal-pdfjournal-book-latexjournal-book-pdfjournal-rdfjournal-rssmuse-journal-heading-regexp父组 1 是 ISO 日期,父组 2 是可选的分类,父组 3 是条目可选的标题。
muse-journal-date-formatmuse-journal-html-heading-regexp父组 1 是 ISO 日期,父组 2 是可选的分类,父组 3 是条目可选的标题。
muse-journal-html-entry-templatemuse-journal-latex-sectionmuse-journal-latex-subsectionmuse-journal-latex-markup-tagsSee muse-publish-markup-tags 获取更多信息。
muse-journal-rdf-extensionmuse-journal-rdf-base-urlmuse-journal-rdf-header这可以是文本或者一个文件名。
muse-journal-rdf-footer这可以是文本或者一个文件名。
muse-journal-rdf-date-formatmuse-journal-rdf-entry-templatemuse-journal-rdf-summarize-entriesmuse-journal-rss-extensionmuse-journal-rss-base-urlmuse-journal-rss-header这可以是文本或者一个文件名。
muse-journal-rss-footer这可以是文本或者一个文件名。
muse-journal-rss-date-formatmuse-journal-rss-entry-templatemuse-journal-rss-enclosure-types-alist这是一个映射文件扩展名到内容类型的列表。
这对于 podcasting 来说很有用。(podcasting 是一种网络录音或者类似的网络音讯软件)
muse-journal-rss-summarize-entries很多 RSS 订阅者感觉这个功能令人讨厌。
muse-journal-rss-markup-regexps关于这个列表构成的更多信息,See muse-publish-markup-regexps。
muse-journal-rss-markup-functions关于这个列表构成的更多信息,See muse-publish-markup-functions。
这个发布风格可以生成 LaTeX 或者 PDF 文档。
如果你想要发布 PDF 文档,你需要有一个安装好的 TeX。对于 Debian 和 Ubuntu 可以安装“tetex-bin”和“tetex-extra”包。TeX 字体也是必须的。
latexpdflatexcjkpdfcjkmuse-latex-extensionmuse-latex-pdf-extensionmuse-latex-header这可以是文本或者一个文件名。
muse-latex-footer这可以是文本或者一个文件名。
muse-latexcjk-header这可以是文本或者一个文件名。
muse-latexcjk-footer这可以是文本或者一个文件名。
muse-latex-markup-regexps关于这个列表构成的更多信息,See muse-publish-markup-regexps。
muse-latex-markup-functions关于这个列表构成的更多信息,See muse-publish-markup-functions。
muse-latex-markup-strings这些字符串涵盖最基本的标记类,它们在各种风格之间的操作差别很小。
muse-latexcjk-encoding-mapmuse-latexcjk-encoding-default如果没有发现特殊字符,该选项将被使用。
muse-latex-markup-specials-example在 <example> 区域的缺省解释下,没有需要被转义的特别字符。
muse-latex-markup-specials-documentmuse-latex-markup-specials-literalmuse-latex-markup-specials-urlmuse-latex-permit-contents-tag大多数时候,最好在第一页有一个目录,紧跟其后一个新页。为了让这个设置在 发布到 HTML 和 LaTeX 文档时都能够工作,我们需要省略 <contents> 标签。
如果你不赞成这样,那么设置这个选项非空,你就会得到你所期望的了。
muse-poem 模块使得以下面的格式发布和引用诗变得简单,使用“memoir”
模块发布 LaTeX。它也可以为每个其他输出风格标记诗章,尽管没有一个能象下面
的这样漂亮。
Title
Body of poem
Annotations, history, notes, etc.
一旦以这种格式写作一首诗,就可以使用 poem-pdf 风格来发布成 PDF。
用这个模块定义的“poem”标签为你写的诗做一个内部引用(比如,从一个
blog 页面)。
<poem title="name.of.poem.page">
我们假设上面的那个模板被命名为 name.of.poem.page,那么上面的这个 标签就会产生下面的内容。
** Title
> Body of poem
John Wiegley 使用这个模块来发布他的网站 http://www.newartisans.com/johnw/poems.html 上的所有的诗。
poem-latexpoem-pdfchapbook-latexchapbook-pdfmuse-poem-latex-header这可以是文本或者一个文件名。
muse-poem-latex-footer这可以是文本或者一个文件名。
muse-poem-markup-strings这些字符串涵盖最基本的标记类,它们在各种风格之间的操作差别很小。
muse-chapbook-latex-header这可以是文本或者一个文件名。
muse-chapbook-latex-footer这可以是文本或者一个文件名。
muse-poem-chapbook-strings这些字符串涵盖最基本的标记类,它们在各种风格之间的操作差别很小。
发布一个 Muse 文件为一个 Texinfo 文章的规则。
muse-texinfo-process-nativelymuse-texinfo-extensionmuse-texinfo-info-extensionmuse-texinfo-pdf-extensionmuse-texinfo-header这可以是文本或者一个文件名,还可以包含 <lisp> 标记的标签。
muse-texinfo-footer这可以是文本或者一个文件名,还可以包含 <lisp> 标记的标签。
muse-texinfo-markup-regexps关于这个列表构成的更多信息,See muse-publish-markup-regexps。
muse-texinfo-markup-functions关于这个列表构成的更多信息,See muse-publish-markup-functions。
muse-texinfo-markup-strings这些字符串涵盖最基本的标记类,它们在各种风格之间的操作差别很小。
muse-texinfo-markup-specials为该风格文本定制函数的风格样式表。
发布风格使用该选项试图将必须定义的自定义正则表达式的数量减到最少。 muse-publish 为最常用的标记类型提供规则。
列表中的每个成员具有如下的形式。
(SYMBOL FUNCTION)
muse-publish-markup-regexps 映射
正则表达式到这些符号。
用 Muse 发布一个页面的标记规则表。
由这个变量给出的规则首先奏效,然后是当前风格指定的任意规则。
列表中的每个成员是一个函数或者一个下面这种形式的列表。
(REGEXP/SYMBOL TEXT-BEGIN-GROUP REPLACEMENT-TEXT/FUNCTION/SYMBOL)
如果它不是一个字符串,而是一个函数,那么它将被调用来决定替代文本应该是什么 (该函数必须返回一个字符串)。如果它是一个符号,那么该符号的值应该是一个字符串。
替代被顺序执行,每次一个规则。写正则表达式可以是一件很需要技巧的事情。 注意有种情形从不会被忽略,在处理标记规则时 'case-fold-search' 总是被赋值为空。
下面是发布规则被查阅的默认顺序,通过自定义 muse-publish-markup-regexps
可以改变这个默认设置。
trailing and leading whitespacedirective它仅仅在文件开头被识别。
tagcommentanchorexplicit links事实上不会在这里发布它们,而是仅仅添加一个专门的非强调文本属性。
word这个函数负责标记强调和转义一些特殊字符。
emdash两个 - 宽的破折号
headingOutline-mode 风格标题。
enddots这些是省略号加最末尾的句点。
dots省略号。
rule水平线或者节分隔线。
fn-sep脚注部分的开始
footnote脚注定义或者引用。如果在一行的开始,就是一个定义。
list有序列表,简单列表或者术语定义列表。
quote块引用。
versetablelinkurlemailMarkup strings 是一个特定风格标记文本使用的字符串。
这些字符串涵盖最基本的标记类,它们在各种风格之间的操作差别很小。
image-with-desc参数 1:不带扩展名的图片;参数 2:图片扩展名;参数 3:描述。
image参数 1:不带扩展名的图片;参数 2:图片扩展名。
image-link参数 1:链接;参数 2:不带扩展名的图片;参数 3:图片扩展名。
anchor-ref参数 1:锚名;参数 2:如果存在就是描述,否则是原始的链接。
url参数 1:URL。
link参数 1:链接;参数 2:如果存在就是描述,否则是原始的链接。
link-and-anchor参数 1:链接;参数 2:锚名;参数 3:如果存在就是描述,否则是原始的链接。
email-addr参数 1:email 地址;参数 2:email 地址。
emdash参数 1:起始的空白字元;参数 2:终止的空白字元。
comment-begincomment-endruleno-break-spacefootnotefootnote-endfootnotemark参数 1:该脚注的数字标号。
footnotemark-endfootnotetext参数 1:该脚注的数字标号。
footnotetext-endfn-sepdotsenddotspartpart-endchapterchapter-endsection参数 1:section 层数;总是1。
section-end参数 1:section 层数;总是1.
subsection参数 1:section 层数;总是2。
subsection-end参数 1:section 层数;总是2。
subsubsection参数 1:section 层数;总是3。
subsubsection-end参数 1:section 层数;总是3。
section-other参数 1:section 层数。
section-other-end参数 1:section 层数。
begin-underlineend-underlinebegin-literalend-literalbegin-emphend-emphbegin-more-emphend-more-emphbegin-most-emphend-most-emphbegin-verseverse-spacebegin-verse-lineempty-verse-linebegin-last-stanza-lineend-last-stanza-lineend-versebegin-exampleend-examplebegin-centerend-centerbegin-quoteend-quotebegin-uliend-ulibegin-uli-itemend-uli-itembegin-oliend-olibegin-oli-itemend-oli-itembegin-dlend-dlbegin-dl-itemend-dl-itembegin-ddtend-ddtbegin-ddeend-ddebegin-tableend-tablebegin-table-groupend-table-groupbegin-table-rowend-table-rowbegin-table-entryend-table-entry一个专门标记文本的标签详表。
XML 风格的标签是最好的添加定制标记到 Muse 的方法,通过自定义这个标记标签 列表很容易就可以完成。
对每个条目来说,不论标签要求一个关闭标签和/或一个可选的属性集,也不论标签 是可嵌套的,它的名字被给出,并且在限定区域内执行任意动作的函数被需求。
发布过程中在函数调用前标签本身会被删除,函数被调用带有三个参数,标签所包围 区域的开始和结束,如果属性允许,那么它们就会以一个列表的形式作为第三个参数 被传递。函数“结束”的参数总是一个标记。
当函数被调用时,point 总是在标签内部区域的开始,当函数结束时 point 在哪里, 标签标记就会在哪里恢复。
这些标签规则在标记开始被处理一次,在结束时又被处理一次,这样做是为了 捕获那些可能被插入到其他标签中间的标签。
风格元素是定义一个风格的标签。使用 muse-define-style 来创建一个新
的风格。
(muse-define-style DERIVED-NAME BASE-NAME STYLE-PARAMETERS)
例如,PDF 发布首先生成一个 LaTeX 文件,然后通过这个 LaTeX 文件生成 PDF 文件。
这些字符串涵盖最基本的标记类,它们在各种风格之间的操作差别很小。
这被用于设置管理发布过程的额外参数。
这被用于修复在类 XML 类型文件中表格元素的顺序(表头,表底,表体)。
这被用于生成目录和设置文件编码系统。
这被用于生成象从刚刚被发布的 LaTeX 文件生成 PDF 文件这样的第二阶段文档。
这可以是一个变量,文本或者一个文件名。它被插入在文件的开始,赋值发布标记后。
这可以是一个变量,文本或者一个文件名。它被插入在文件的结尾,赋值发布标记后。
这可以是一个变量或者文本。它被用于基于 HTML 和 XHTML 发布风格的页眉。
下面使用 muse-derive-style 来从一个存在的风格生成一个新的风格。
这对于修改一个独有发布风格中你不喜欢的地方或者个性化这个发布风格是一个
好的方法。
(muse-derive-style DERIVED-NAME BASE-NAME STYLE-PARAMETERS)
DERIVED-NAME 是定义新风格的一个字符串,比如“my-html”。BASE-NAME 必须是 一个存在的风格,比如“html”(如果你加载了 muse-html)。 STYLE-PARAMETERS 与用来创建一个风格的参数相同,只是它们去掉了基风格中存在 的所有定义。但是,一些定义仅仅部分弃除。下面的这些参数支持部分弃除。
See Style Elements,获取所有参数的完整列表。
阅读完这个手册后,对于 Muse 如果你仍然有疑问,或者有 bug 要报告,有这么 几个地方你可以去。
你可以从 http://mail.gna.org/listinfo/muse-el-announce/ 订阅加入这个
邮件列表(muse-el-announce@gna.org)。这个邮件列表在 Gmane
(http://gmane.org/)上也可用,邮件组叫做 `gmane.emacs.muse.announce'。
你可以从 http://mail.gna.org/listinfo/muse-el-discuss/ 订阅加入这个
邮件列表(muse-el-discuss@gna.org)。这个邮件列表在 Gmane 上也
可用,邮件组叫做 `gmane.emacs.muse.general'。
你可以从 http://mail.gna.org/listinfo/muse-el-commits/ 订阅加入这个
邮件列表(muse-el-commits@gna.org)。这个邮件列表在 Gmane 上也
可用,邮件组叫做 `gmane.emacs.muse.cvs'。
你可以从 http://mail.gna.org/listinfo/internationalization/ 订阅加入 这个邮件列表(muse-el-internationalization@gna.org)。这个邮件列 表在 Gmane 上也可用,邮件组叫做 `gmane.emacs.muse.internationalization'。
主要由于 Planner 还没有被移植到 Muse 的原因,多数经常访问 emacs-wiki 邮件 列表的用户仍然使用 emacs-wiki。
大概在 2004 年 12 月 1 日,在 John Wiegley 的请求下,Michael Olson 成为了 Muse 的维护者。
这个文档的第一个草稿来自 emack-wiki 的 texinfo 手册。Michael Olson 为 Muse 改写了它并增添了很多关于 Muse 的内容。
emacs-wiki 的 texinfo 手册的大部分工作是由 John Sullivan 完成的。
而 Sacha Chua 维护着 emacs-wiki,她在 emacs-wiki 的 texinfo 手册上也付出了很多。
Copyright © 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
one line to give the program's name and a brief idea of what it does.
Copyright (C) yyyy name of author
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items—whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.