自定义全拼方案
上一节讲完双拼，这一节来讲讲全拼。全拼的输入规则想必大家都清楚，我就不多赘述了，下面分情况和大家介绍用带条件的前置路径如何表示吧。
- 表示zh/ch/sh：
z:h=zh c:h=ch s:h=sh - 表示长韵母，以uang为例：
可以看到，这里相当于是将韵母的变化情况用带条件的前置路径描述出来。uang属于所有前缀都是合法韵母的情况，但同时也存在一些韵母前缀不都是合法韵母的情况，比如iong。但没有关系，带条件的前置路径一样可以描述：u/_u:a=ua ua/_ua:n=uan uan/_uan:g=uang
前面两个例子中都是韵母条件和下划线+韵母条件的情况，但并不是非得这么写不可的，这么写只是在不影响实际使用的前提下加入的方便输入，考虑到io、ion、iong一般不会省略声母，所以写成：i/_i:o=io io/_io:n=ion ion/_ion:g=iong
也是对的。_i:o=io _io:n=ion _ion:g=iong
以此类推，我们就可以得到全拼的前置路径表示：
z:h=zh
c:h=ch
s:h=sh
a/_a:n=an
an/_an:g=ang
a/_a:i=ai
a/_a:o=ao
o/_o:n=on
on/_on:g=ong
o/_o:u=ou
e/_e:n=en
en/_en:g=eng
e/_e:i=ei
e/_e:r=er
i/_i:n=in
in/_in:g=ing
i/_i:a=ia
ia/_ia:o=iao
ia/_ia:n=ian
ian/_ian:g=iang
i/_i:e=ie
i/_i:o=io
io/_io:n=ion
ion/_ion:g=iong
i/_i:u=iu
u/_u:n=un
u/_u:a=ua
ua/_ua:n=uan
ua/_ua:i=uai
uan/_uan:g=uang
u/_u:o=uo
u/_u:e=ue
u/_u:i=ui
v/_v:e=ue
b4=b
c4=c
d4=d
f4=f
g4=g
h4=h
j4=j
k4=k
l4=l
n4=n
m4=m
p4=p
q4=q
r4=r
s4=s
t4=t
w4=w
x4=x
y4=y
z4=z
04=0
i4/i44=ch
u4/u44=sh
v4/v44=zh
与双拼类似的，我加入了下滑输入声母的前置路径，同样是为了优化拼音替入效果。
现在我们就可以在岁寒上使用全拼输入方案了。同样的，我们在使用的全拼的同时，也可以享受到岁寒输入法的各种特色功能，如笔画筛选（加形可能就不是很有必要了）、拼音替入、截断优先、历史回溯等等。
但这个实现方案下的全拼存在一个瑕疵，就是在输入n或g时，可能出现前一个拼音将n或g“夺走”的情况。比如我们想要输入“可能”的拼音，按拼音顺序输入是“keneng”,此时，岁寒输入法会识别得到“ken'eng”，而不是一般全拼输入法的“ke'neng”。这是因为这种组合本身是存在歧义的，一般的全拼输入法会根据拼音频率选择更常见的“ke'neng”。而岁寒是按顺序接受输入的，考虑到路径n和韵母条件e满足带条件的前置路径表达式:e/_e:n=en，而k又正好能与en匹配，从而触发了表达式，所以这种结果本身是没有毛病的，只是与我们日常的使用习惯不太相符。那这种情况要如何解决呢？方法是在可能出现这种情况的地方使用下滑输入n或g，这样就可以避免触发e/_e:n=en表达式。我知道这种建议有点类似与苹果公司建议用户换一种手机持握方式，此种情形的存在其实是岁寒输入法的设计逻辑和全拼拼音方案不相契合导致的，因为岁寒是拒绝歧义的，而全拼却又不可避免的存在歧义。如果可能的话，我会引入一些机制来纠正这种情况。
使用全拼时的建议
如果使用全拼输入方案的话，可以在输入设置中将删除键的操作改为以字母为删除单位，这样会更加符合全拼下的实际使用习惯。