-
Notifications
You must be signed in to change notification settings - Fork 568
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
关闭/打开输入法,ascii_mode会强制变为中文状态 #581
Comments
不,沒有任何針對Control+space的特殊考慮。 |
已经退回到0.11.0版本的小狼毫进行过确认。在这个版本(IME或TSF均可),英文模式按ctrl+space切换两次仍为英文模式,同样中文模式按ctrl+space切换两次仍为中文模式。因此最新版0.14.3的行为必然是一个bug。即便如楼上所说,新版中输入法被重置,那么为何在我设定了初始英文模式的前提下,使用win+space可以实现初始英文,使用ctrl+space却会被强制为初始中文呢? 0.11.0与0.14.3使用同一套配置文件测试,因此我认为大概率不是后端Rime,而是windows前端weasel的bug,这也是我把issue发在这里的原因。另外还测试了0.12.0,此bug已经开始出现,推测可能是合并IME与TSF时引入的新bug。 |
GVim 下默认 iminsert=0 也会在进入 insert mode 时自动切换到中文状态。另外中文状态又时常会失效,即小狼毫图标显示为「中」而实际为英文状态,必须切换到非输入法状态,再切换回输入法状态,才能解决,bug 触发条件不明。 |
好像找到问题根源了。
以前加入输入法disable图标的时候添加了这个“重新开启输入法时强制将 ascii_mode 设为 FALSE“的行为。 |
0.11 版本就没有问题。在 Insert 模式下是英文输入状态(ascii_mode = true),进入 Normal 再回到 Insert 时,依然是英文输入状态。另外也不存在 Normal 状态下键入 r,f 等 motion command 时会激活输入法。恢复到 0.11 版本的行为就行。 |
也有这方面的困惑,希望关闭输入法后再恢复时,不要改变之前的ascii_mode状态。 |
一直关注这个问题,目前使用Rime输入法最大的痛苦就是在Vim中输入法总是会切换到中文。 |
在Windows 10语言设置中加上英语,输入法会增加一个英文键盘(需要注意调整语言顺序为中文优先,英文靠后,以免windows 10专业版中用户界面全部变成英文)。然后改变自己的使用习惯从按Ctrl+space改为按Alt+shift,就能从根本上解决问题。在按过Alt+shift切换输入法为英文键盘后,使用Vim绝对不会和英语用户有任何差别,需要输入中文时再按Alt+shift就立即回到了RIME。 |
反对,理由见我的上一楼。如果我按Alt+shift切回中文输入法后,不能立即输入中文,会很麻烦,还需要记忆上一个状态,降低使用体验。 |
1、你还没理解到这个问题的实质。关闭输入法和切换输入法是两个不同的操作。切换输入法到RIME后ascii_mode状态是可以通过配置文件设置的。但关闭输入法后再打开输入法是无法通过配置文件设置的。 |
@YeMeiLiHui 所以我就不使用这个不可靠的RIME英文状态啊,不需要中文输入的时候,我不用单击Shift或者WIN7以前的使用习惯按CTRL+SPACE让RIME到英文输入状态,因为windows 10的Ctrl+SPACE功能语义完全和以前的版本不同了,我改变自己的习惯(需要大概一周时间),忘记了CTRL+SPACE,永远不去按它。如果你实在忘不了CTRL+SPACE,而且不玩网游,可以用ahk将CTRL+SPACE按键组合映射为ALT+SHFIT。 |
@YeMeiLiHui 这是我的AHK脚本,按Ctrl+space出Alt+shift
|
@nobk 可能是我太迷恋SHIFT键了吧。我目前的解决办法跟你一样,添加一个简体英文键盘,通过切换键盘来使用英文输入。 |
按SHFIT改成Alt+SHIFT其实动作上并没增加多少,什么都不用安装修改就解决了。
|
@YeMeiLiHui 要是能提供一个可选项,两者都支持,其实我也没意见。 |
你好,我测试了一下在gvim中如果不加载vim插件,可以愉快的使用rime输入中英文。请问,据你所知除了coc和autopair外,youcomplteme是否也会导致失效?还有没有其他的插件。我再考虑是否从gvim插件入手,避开此类插件。我目前使用的插件包括:ctrlp,vim-airline,ale,indentline,autopairs,nerdcommenter,ultisnips,vim-snippetrs,vim-template,coc,fastfold |
问题根源不在于插件。我开issue的时候已经说的很清楚了,只要从insert返回normal再进入insert就会重置中文。即使不用插件,中英混输加修改编辑的情况也很常见,比如改带中文,中文注释的代码(说的就是你rime的配置文件!)。自行定义一个imap,比如 imap <M-B> <ESC>bi,就可以重现这个bug,打断在insert模式中的英文状态。你所谓的愉快的输入中英文,可能只有前期专心输入不做修改的时候没问题。 |
用Vim写代码这种基本用不到中文的情况下,按什么组合键切换都无所谓,反正极少用到。但是用Vim写大篇幅的中文文档时,就很痛苦了。单个Shift键一定比 Alt+Shift这种组合键高效的多,尤其是在输入(Insert mode)和编辑(Normal mode)频繁切换的情况下。为什么 0.11版本完全正常,到了0.12开始就不行了? |
跟插件没有任何关系,即使一个插件都没加载,一样有问题。 |
#567 似乎也是同样的原因造成的,因为 Quicker 会暂时关闭并重新开启输入法,导致小狼毫变为中文输入 |
即使不考虑 windows api 的问题。小狼毫的 weasel.custom.yaml 是可以设置特定 exe 窗口下的 ascii_mode 默认开/关的,如果禁用再启用,应该根据 weasel.custom.yaml 的设置来决定。 |
说的太对了,三个事情要分清楚: 1、不同输入法之间切换, Alt + Shift Rime 在 GVIM 中的问题就是中英文状态没有起作用,只能关闭和打开输入法,但打开之后默认是英文,没办法输入中文,导致的问题就是: 1、Insert 模式,中文输入,此时中英文状态为中文; 在 #468 中“SendMessage无法获取中英文状态,微软拼音却正常” 中也有讨论,可以获取微软拼音的英文状态和中文状态,但获取 Rime 的 ascii_mode状态,不管是中文状态还是英文状态,返回都一样,说明是没有办法区分的。 |
不知道现在问题解决了没有,看到上述有些解决方案。准备有时间尝试一下。我在使用NeoVim还有Visual Studio Code 的Vim插件。如果带自动切换输入法的,都会重置Rime到中文状态,每次都需要多按一个Shift。现在的解决方案不用切换插件。然后只有Rime,然后人工切换,至少思路不会被打断。缺点是一直要手动切换输入法。这样很麻烦。要是能记录切换前的Rime的ascii_mode就好了 |
我用 vscode 是,总是给我切到英文状态。。。。非常的纳闷。 |
keepass 也有这个问题,英文状态下所有地方强制给我转换成中文输入 |
我用vsc的neovim mode, 中英文切换也是非常麻烦 |
没想到这个issue开了两年都没解决,vim重度用户在Windows平台已经放弃rime了。 |
这里有一个pull解决了这个问题 |
fixed by #1096 |
我和你习惯是一样的,我有不会轻易变化的英文语言用来敲命令行(我用shift敲大写字母),和一个可以变化的搜狗/RIME。中文打字时,至多两次win+space 或者 alt+shift就能找到中文输入法。而微软拼音会记住ascii mode,按一辈子也找不到中文。 |
对于当前大多主流输入法而言,中英模式与打开/关闭输入法状态是统一的。
对于小狼毫并非如此,因而输入法会有三种状态,中,英 (ascii_mode off/on) ,以及输入法关闭状态(图标显示为x)。
当前行为:在英文模式下关闭输入法,再打开输入法,会被强制切换为中文模式。(若自行定制了默认英文模式也不会生效)
(应该是在0.11版本之前,打开输入法会恢复为关闭之前的状态)
为什么这是一个bug?先来看这几种状态的区别:
相信对于大多数场景,可自行定制的中英模式切换是更好的中英混输方式。输入法关闭状态基本只在快捷键冲突(PS,IDE等,靠定制快捷键可以解决特定程序,但是除非完全取消快捷键,不然总是会有冲突)的情形有用。
当前的行为“打开输入法强制中文状态”可能是考虑到用户手工(ctrl+space)切换到打开状态应该是想要输入中文。但是:
综上,希望能够采用旧版行为打开输入法恢复为关闭之前的状态。
The text was updated successfully, but these errors were encountered: