感谢前辈！第三条建议确实是不行的，那样生成的正则遇到行尾可能会出现一些问题，会导致报错……其它地方我都做出了修改 
不存在替换的问题。cl-return 一直都在 cl-macs 文件中，以前使用 return 是因为那时大家都习惯 (require 'cl) 这样大包大揽的导入方式，现在已经不推荐了。
1 个赞
我使用的是python 3.10, 我根据您文档中的建议将CBTaggingDecoder.py中的start = time.start()改为start = time.pref_counter()。
但是并不能工作，将其改为time.perf_counter()后方可运行，您可能写错了。
2 个赞
感谢你的指正！很高兴看到有人使用我写的小插件！
这确实是我的巨大疏忽，先前我还遇到过这个问题，转眼就给忘了🤣
README已修改，祝你用得开心，我会继续努力的~
（其实据说可以直接删掉那一行……我是没试过啦哈哈）
2 个赞
好像是的，后面的代码没有用这个变量。
我刚刚测试了，删掉也可以用。
使用时message buffer中出现大量的
Invalid face reference: quote [770 times]
哇，谢谢你愿意使用它！当初初学elisp编程，写的代码还是太稚嫩了些，很抱歉给你造成了麻烦quq
我在使用的时候并没有遇到这样的问题，不过我猜测问题大概发生在操作overlay的部分。不仅这里，整个cnhl中大大小小的问题也太多了，如果你不介意的话，我这段日子再重写一版，把一些必要的功能加进去，重写完后再通知你ww
蓬山此去无多路，青鸟殷勤为探看
1 个赞
很喜欢你的包，写笔记的时候可以中文分词了。 这里找到一个新 bug：
+ 在明确评价机制的基础上形成伺服系统的指标要求，据此找厂商定做伺服系统。
上面这行文本（注意前面有两个空格），在使用cnhl-forward-word将光标移动到中间的逗号以后，出现如下错误
Debugger entered--Lisp error: (args-out-of-range [["+" "w"] [" " "g"] ["明确" "a"] ["评" "v"] ["价" "n"] ["机制" "n"] ["的" "u"] ["基础" "n"] ["上" "f"] ["形成" "v"] ["伺服" "v"] ["系统" "a"] ["的" "u"] ["指标" "n"] ["要求" "n"] ["，" "w"] ["\n" ""]] 17)
cnhl--current-word-info()
cnhl-forward-word()
#<subr funcall-interactively>(cnhl-forward-word)
apply(#<subr funcall-interactively> cnhl-forward-word)
funcall-interactively(cnhl-forward-word)
#<subr call-interactively>(cnhl-forward-word nil nil)
apply(#<subr call-interactively> (cnhl-forward-word nil nil))
explain-pause--wrap-call-interactively(#<subr call-interactively> cnhl-forward-word nil nil)
apply(explain-pause--wrap-call-interactively #<subr call-interactively> (cnhl-forward-word nil nil))
call-interactively(cnhl-forward-word nil nil)
command-execute(cnhl-forward-word)
1 个赞
啊，我明白你的意思了！
谢谢你的提醒，我这次会采用新的方式来计算所有的位置信息！
幸与同窗多济路，长歌一奋不孤征 ——我的旧诗
2 个赞
后生可畏！
我虽然技术没有楼主那么高，但还是想厚着脸皮提点思路，毕竟语义分词听上去就感觉运行起来应该不会很快：
我们在实际使用的过程中（假设简体中文环境），可能不需要那么具体与准确地对语义进行区分，只要能大概分一下主谓宾就可以了。比如「我其次/喜欢/的/是/历史。」这句话，断成「我/其次喜欢的/是/历史。」，我想对于大多数人就够用了。具体来说，除了表示「目的」这一意义的少数词语、成语，「的」字前边的一般都是定语；「什」很少有单独使用的场景；而「们」字一般都跟人称代词有关……那么如果预先建立一个词库，并对其中的词语如「有的放矢」「实事求是」等高亮，剩下的部分以「的」「是」等关键字断开，是不是就能提高cnhl的运行效率了。同时作为Emacser，我也希望这个项目能以纯elisp的方式实现。
插一句题外话，我姑且作一推断，这几句诗创作的时候没有查韵书。「天」和「添」现代普通话同音，近体诗里却不能通压，他们甚至都不属于同一韵摄。我个人认为学点音韵对于格律是有帮助的，比如「出」字古代也是仄声，严格来说颔联出句也是失黏失对的。
谨代表个人意见。
2 个赞
谢谢！谢谢你的建议！
前辈太谦虚啦，我一个文科生可没多少技术，不过是为了不负大家的一片心意，赶鸭子上架啦哈哈 
这个小功能本身依赖于thulac，包括它的算法、程序和模型，所以它的功能自然会受到thulac的限制，这点也特别令我火大……怎么说，果然理论和实践是有区别的。
就像你说的，词语功能分的那么细其实并不是最适合写作的；此外thulac通过现在这种方式调用也有非常多的问题，比如那个莫名其妙的800字一断——其实也是我代码水平太菜qaq。
我原本是打算用dynamic module的——其实c的部分已经写好了 
——但听完你的期待后，我也有点想用elisp实现一个词法分析功能了。我也希望能有更多的elisp项目丰富我们的世界。
简单的搜索与位置判断大概是不行的，结果会很容易出错。我先试着啃一啃thulac的源码，如果做不到的话就去请教一下信竞的朋友，实在做不到再用dynamic module，然后试试训练更简单的模型。谢谢你，谢谢你们！ 
竟然能在这里遇到懂诗的同学！有朋自远方来！
近冠犹懂习翰墨，寸管悬悬总二更。
一捧沁脾天作韵，不离辗转绕梁声。
未潜书海至终老，敢请文心许此生。
幸与同窗多济路，长歌一奋不孤征。
（八庚）
上个回复里引的那句的全文，也是我想送给大家的！
感谢你的指点，长知识了！不过其实我是不抗拒新韵的。我一般是在用平水的时候注明韵部，新韵的时候则不注明，像上面那样，刚好和很多人相反 可能是因为我开始写诗时新韵用的比较多吧，或者是虚荣心的原因呢？～
不过关于新韵，其实目前也确实褒贬不一，经常就会听一个教授前脚喷完新韵，另一个教授后脚就说“有些人顽固不化”…… 诗人真的和程序员一样可爱ww
用结巴分词.
结巴没有词法分析的，而且如果只是分词，结巴和thulac并不会相差太多，thulac官网上有比对数据 
1 个赞
执行力真强啊！
希望你也不要放弃现有的thulac，如果将来能用elisp实现最基本的功能，并为使用者提供更多可选的特性是最好的。
我也不反对新韵，毕竟「诗言志」嘛，不是专业研究音韵的话，也没必要循规蹈矩，只要遵循一点格律，读起来富有美感就可以了。现代人可以不讲究那么多，拗了实在救不回来也无伤大雅。
我反对的主要是两类人：一是明明写得老干部体打油诗，却偏偏自信心爆棚，弄得大家都没法接他的话 
二是有很多人用汉语拼音的拼写来通押，把记音的规则用作转写的方案，这也太懒了，写出来的文章质量可想而知。
谢谢你！就我的了解，两个项目的方向是不同的qwq 如果我的理解不当还请指出来
单纯对比一下分词功能的话，pyim的分词是基于查询用户词典的，而thulac是是用算法模型，所以thulac会有一些语义分析功能；同时因为pyim基于用户词典，所以本质上算是解析用户已知的词句；但thulac自带的模型载有一千余万词，主要是用来分析用户位置的词句的。
另外，thulac lite模型只有50M，如果要按照pyim的实现方式做出thulac的效果，可能各个方面都会炸掉 
谢谢！睡一觉后我也从冲动状态走出来了，还是先用thulac重写出新的cnhl来，让大家用上先，再试着构筑自己的模型和后端，不能膨胀不能膨胀
哈哈确实，教我诗词的老师天天跟我强调近体诗的格律，自己写的却全是古体，超级可爱
我们有个政治老师就特别喜欢写老干体哈哈哈哈！每次他跟我们分享他的新作时我都是这个表情：(///▽///)
pyim带的分词功能很原始，就是暴力匹配，用来提取光标处的词语可以，大面积分词性能不行
啊，今天我写cnhl的时候忽然遇到了这个问题，便仔细想了想。其实除了提示外，在我的设想中，cnhl作为一个词法分析工具还有一个重要的功能——帮助作者了解、进而自己所写的内容。
这涉及到一个文风的问题，譬如有些同学会在写作中使用大量的形容词，有些同学会用很多名词组成大长句子什么的，如果cnhl能够把这些东西直观地体现出来，那这对于作者写作水平的进步是会有很大帮助的，譬如通过删掉过多的形容词和助词来避免啰嗦，或者在急需水字数的时候帮助作者见缝插针 我觉得这也应该是cnhl的主要功能之一，它不只是一个花瓶ww
但按照主谓宾句法高亮确实会更加美观易读，而且也还能做到一些揪病句这样的功能，一样十分有帮助。不过这就不是thulac作为一个词法分析工具能够做到的了，这需要句法分析工具的支持（如果只是把助词、连词等并入上一个词的颜色，是没有明显效果的）。
我找到了一个百度Apache2.0开源的句法分析工具DDParser，我觉得可以给cnhl开发一个以它为后端的句法高亮功能。这会有一些难度，但我预估了一下，大概还在我能够得着的范围内
如果真的决定的话，我会先把thulac版重写完毕再开始。
抛砖引玉，请教一下大家有什么建议ww……
简体中文还有一些多音字、多义词是因为一简对多繁引起的，繁体似乎可以较大程度地避免，我还不太理解opencc是如何实现的，你看能不能汲取一些灵感。
我也在想，作为分析语，把汉语的句读交给程序分析，这本身也许就注定无解