全部用mingw64编译的librime和liberime搞定了，发现少了一个libstdc++6.dll，加上就能用。
我再看看用vc编译的rime.dll报错是什么原因。现在机器上的dll有好几套，3个版本的emacs，windows的path都给搞乱套了。哈哈
官网的librime是32位的dll，所以只能给32位的emacs使用。
我现在没有Windows系统，猜测小狼毫在win下应该是32位的程序。
那么如果没有最新liberime里readme说的opencc格式vc和gcc的兼容问题，和系统带的rime共享数据应该没问题。
msys2/mingw要以32位模式进入/运行。也可以强制在cmake里加-m32的编译链接选项（如果工具链支持混合，如tdm-gcc）
64的emacs只能加载64的dll，64的linerime也只能加载64的rime.dll。官网的sdk是32位的。
我昨天试时，特意下载的27的32位的pretest
昨天专门下了mingw32，link时报错，没搞定。又再64bit的mingw64里试了，dlltool从32bit的librime.dll生成librime.a，一顿操作后，居然编译成功。但是在64bit的emacs里就是报错。
今天从librime.dll到liberime.dll都用mingw64编译，果然能用。从官方pretest 28.0.50到自己编译的最新的native-comp分支都可以用。但是可能和windows上32bit的小狼毫没法混用一套配置了。
我觉得win10自带的微软拼音比rime好用。。。emacs用pyim+liberime+librime，其他还是微软拼音吧。
不知道为什么vim里用rime能无缝衔接，感觉太好了，按esc就马上切回asc ii mode。emacs就要一堆配置才能搞定。
大概gVim里硬编码了系统切换输入法时换模式的逻辑
gvim里用rime丝般顺滑，奇怪的是neovim都不行。哈哈。难道我装了什么plugin。。。
这个不错，用这个编译64位的不用多想事了。要用mingw的shell不是msys的shell,路径加了的就没事。
我直接把 liberime.dll 拷贝了一份到 /mingwxx/bin, 所以一般情况应该不需要用户设置环境变量，可能只有拷贝别人预编译dll的用户才需要设置。
librime.dll、libmarisa-0.dll、libopencc.dll、libstdc+±6.dll最好是copy到emacs的bin目录，或者在%PATH%里面的任何一个目录都可以，windows会在path里面找。
liberime.dll 在liberime-config.el里配置了默认是 liberime安装包/build 目录。
上面写错了， librime.dll 已经拷贝到 /mingwxx/bin
这两天做了比较大的调整， liberime-config.el 已经迁移到 liberime.el, 依次从 build load-path 和 exec-path 三个地方搜索 liberime-core 模块
不拷贝这几个好像也可能正常运行，也许 librime 会自动从 lib 目录搜索
你用runemacs.exe启动的话，如果没有装mingw64或者mingw64不在PATH里，emacs就会报错 “module cant be loaded”。
有个问题没测试过，就是如果没装mingw64，同时librime和liberime也没装，而是用直接用的dll文件，librime会不会在~/.emacs/rime下生成rime的配置文件。
昨天看见你在liberime的pr了，等稳定一些，pull下来，试试。现在pyim+liberime+sqlite用得稳定。
这种情况下，我觉得就应该设置PATH了，我一般是先运行 msys2 然后在运行 emacs ，最后把 msys2 的黑框隐藏
我添加的打包功能， 把所有的dll和 rime schema 都打包到一起，不过还没有做细致测试
要不是为了编译emacs，我都懒得在机器上装mingw64，windows上的git搞了一套命令行，我的mobaXterm有一套cygwin的，搞得PATH里面好乱。
不知道应不应该把预编译的 dll 放到网上
可以的。这样可以把使用rime和pyim的门槛降下来。不是每个人都愿意去自己编译源代码来安装。
不过不知道对emacs的版本有没有要求。
我在 release 页放了一套32位的预编译包，作为测试使用。
我试了可以用 travis-ci 自动构建windows的包。等我测试通过后可以考虑加上去。