Skip to content
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

以tab键给前面的文字追溯修改輸入码后造词功能不能正常发挥作用 #830

Closed
cjwdoing opened this issue Oct 30, 2018 · 20 comments · Fixed by #831
Closed
Assignees

Comments

@cjwdoing
Copy link

作者给出了RIME使用辅助码的方案,也就是给一个字关联多种拼音(带辅助码的和不带辅助码的)的方案。但这导致了一个问题,就是使用带辅助码的拼音打出一个词后,这个词没办法用不带辅助码的拼音打出来。想要正常使用的话,还需要用不带辅助码的拼音重新打一遍这个词。

请问有什么解决方案么?

@lotem
Copy link
Member

lotem commented Oct 30, 2018

作者是誰?給出的方案具體是怎樣寫的?願聞其詳。
似乎與我直觀的想法不同。

@cjwdoing
Copy link
Author

cjwdoing commented Oct 30, 2018

@lotem 作者就是指您啊~

http://tieba.baidu.com/p/2094178562 这个应该是您的文章吧,我按照这个文章来做的

然后造词的时候出现了上面所述的问题~

比如“韦薇”这个人名,操作的方式是,先输入不带辅助码的韦薇的拼音,然后按tab键在韦这个字后面追加输入辅助码,然后选中韦字;之后在薇的位置也追加输入辅助码,然后就出现韦薇这个词了。但是这时这个词一定是要输入两个带有辅助码的音才能出现的,如果输入的是韦薇的不带辅助码的拼音的话,就不会出现这个词。

@cjwdoing
Copy link
Author

对了,我用的就是双拼+1的辅助码方案哈

@lotem
Copy link
Member

lotem commented Oct 30, 2018

程序現在不支持輔助碼呢。這屬於用技巧加蠻力實現。
我的文章裏一個字還是對應一個編碼,只是允許只輸入編碼的一部分來檢索。一樓描述的情況好像是不一樣的。

@cjwdoing
Copy link
Author

@lotem 您是有写到“只需考虑两个问题:如何以拼写运算描述省略辅助码的规则;”这句话来着。

事实上我的码表也是每个字对应的唯一的拼音(带辅助码的),然后用derive使得带辅助码和不带辅助码的拼音都可以输入。应该和您说的是一个意思。

然后就会触发上面所描述的问题。(当然我不确定问题的原因到底是由于保存了自造词,但所保存的拼音是带辅助码的版本,还是使用辅助码时会不保存任何的词,只是由于自动调整了词频,导致再次输入相同的带辅助码的拼音后,虽然没有造词,但看起来像有了那个词一样;这里我假设是前者)

如果上面我描述的问题确实会存在的话,我正在考虑更改源码,让程序在保存词语的时候,尤其是输入带辅助码的拼音后,自动保存不带辅助码的拼音(因为我用双拼,每个字只需要保存两个字母就好,应该需要的处理不大)。不知道是否可以请您可以直接指教一下,想要做到这一点,应该修订哪个文件的哪里:-)

感谢!

@cjwdoing
Copy link
Author

cjwdoing commented Nov 1, 2018

哈,搞定了~~

深入的看了源码,原来上面括号里理解的是错的,恰恰是另一种情况,也就是说其实是由于RIME的单字不调整词频的策略导致的使用tab键选字以后不会自动造词(看了作者的说明,好像是特意加上那个设定的),把那段代码注释掉以后,就可以非常正常的在使用辅助码输入以后使用造词功能啦:-)

@nameoverflow
Copy link
Member

单字不调整词频的策略?
不会是方案里没加 enable_user_dict 吧?

@cjwdoing
Copy link
Author

cjwdoing commented Nov 1, 2018

@nameoverflow 感谢您的回复~

不过这个问题似乎和您提的那一点无关,而且我也是开启用户词典了哒:-)

我说的是代码中下面这部分导致的问题~

if (commit_entry.elements.size() > 1) {
for (const DictEntry* e : commit_entry.elements) {
if (e->code.size() > 1) {
update_elements = true;
break;
}
}
}

@lotem
Copy link
Member

lotem commented Nov 2, 2018

樓上這段邏輯是說組成新詞的單字不調頻。
比如組詞「狄赤」之後,單字「狄」不會因此獲得很高的字頻。
改動此處不像能解決樓主描述的問題。

@cjwdoing
Copy link
Author

cjwdoing commented Nov 2, 2018

@lotem 哈,感谢回复~

是这样的,确实不能“直接”解决我原来的问题。但是如上的改动“很大一部分”解决了之前的问题。

因为改动之前,我组词「狄赤」(或者一个由更生僻的字组成的词)之后,再次输入这个词,不使用辅助码的情况下会发现其中的字需要翻很多页才能找到(因为字没有被调频,比较生僻的字的位置比较靠后)。

但是做了如是改动以后,首先用辅助码输入词语,然后再次输入时,不用辅助码的情况下很多时候不用翻页就可以直接找到这个字(因为单字已经调频了),然后以不使用辅助码而直接选字的方式输入这个词,系统就会记录这个词了。

正如作者所言,没有“直接”解决问题,但是很大程度上帮助我解决了问题:-)

(毕竟这样的修改比较简单,只要注释几行就可以搞定了;我看了一下,好像让系统支持辅助码选字以后也能自动组词的话,需要做的修订比较多;当然,也可能是我对源码的了解不够深入,如果作者能够指出一个能达到目地的修订源码的方式的话,就更好啦:-))

@lotem
Copy link
Member

lotem commented Nov 2, 2018

原題說的是「词没办法用不带辅助码的拼音打出来」,可見這個問題並不存在。

組成新詞的單字不調頻,是因爲輸入人名等造詞的場合,單字並不是以「詞」的形式使用,調頻會把不需要單用的生僻字置於前列,對同音的高頻字形成干擾。

@lotem lotem closed this as completed Nov 2, 2018
@cjwdoing cjwdoing changed the title 使用带辅助码的文字方案后造词功能不能正常发挥作用 以tab键给文字加辅助码后造词功能不能正常发挥作用 Nov 2, 2018
@cjwdoing
Copy link
Author

cjwdoing commented Nov 2, 2018

@lotem 好吧,我终于知道为什么看起来这个沟通的过程非常不流畅了。

好像确实是我的标题没有清晰的说明我的意思,抱歉。

现在重新说一下哈。比如「狄赤」一词,如果我的操作是直接打出两个字的带有辅助码的拼音,那么造词功能会是正常的。

但是如果我先打出两个字的不带辅助码的拼音,然后按tab键回到第一个字,加上辅助码,然后选出这个词,这时RIME会把这个词当成两个字,而不会自动保存这个词。但是其他输入法在这种情况下会自动造词。

我是希望RIME在如此操作下也可以自动造词来着。(之前我修改的那个调单字位置的代码,正好可以缓解这个问题)

抱歉之前是我的标题没说清楚……

不知道这次我有清晰的说明自己遇到的问题吗?我是否应该再开一个issue?还是继续在这个issue下沟通~?

@cjwdoing cjwdoing changed the title 以tab键给文字加辅助码后造词功能不能正常发挥作用 以tab键给前面的文字追溯增加辅助码后造词功能不能正常发挥作用 Nov 2, 2018
@lotem lotem reopened this Nov 2, 2018
@lotem
Copy link
Member

lotem commented Nov 2, 2018

針對新情況,我以拼音類比這個操作步驟,仍無法重現問題。
測試步驟:
仍以「狄赤」一词爲例,輸入 dch,相當於拼寫運算產生的「不帶輔助碼的拼音」,然後按 Tab 鍵跳到 d 之後,輸入 i 仿真「加上輔助碼」,然後選取「狄」,再如法完成「赤」。結果是上屏後,「狄赤」這個詞可以用各種拼音形式輸入,並出現在同音候選詞前列。

你改的那段算法只影響各個組分即「狄」「赤」兩個字是否記憶,而最終上屏的詞組「狄赤」一定會記錄。

@cjwdoing
Copy link
Author

cjwdoing commented Nov 3, 2018

@lotem 确实是这样,我也像您那样输入狄赤这个词的话,确实是可以记录的。

那么,相应的,我也给出一个不能记录的例子哈。

比如我输入“皇氏”(我用的双拼版本的拼音为hd ui)一词,那么我先输入hu,然后按键盘左键让光标到达h和u中间,然后输入d(就变成了hdu),选中皇字(皇的位置不是第一个),然后输入区域的状态为“皇u「光标」”,这时再输入i,选中氏字(氏的位置也不是第一个),然后就会发现不能自动记录这个词来着。

再比如,我输入“爱奇艺”(双拼拼音ol qi fi),先输入olqif,然后按左键,调整光标位置到ol这里,选中正确的“爱”字,然后光标自动跳到qi这里,我再选中正确的奇字,然后光标自动跳到f这里,我输入i,再选中正确的艺字。这时再输入olqifi会发现这个词是没有被记录下来的。

不知道这样的操作方式,您那边能触发问题吗?(现在看来,也许是前面的字都选好后,再给这个词最后的字加字母的时会影响造词功能?因为我以前如果决定输入辅助码的话,一般这个词的中间和最后的字都会加辅助码,所以也没太区别修订词组中的字和词组中的最后一个字时RIME的表现是否相同来着,标题也直接写了给前面的字加辅助码影响造词,现在看来可能这个标题也不严谨,不过暂时先不改标题了哈,等确认确实是这个问题后再改~)

@lotem
Copy link
Member

lotem commented Nov 3, 2018

@cjwdoing 這跟我造「狄赤」這個詞的操作不是一樣麼?

@cjwdoing
Copy link
Author

cjwdoing commented Nov 3, 2018

@lotem sorry,确实,我想可能是因为上面那次按照您写的方法操作的时候,没有严格按您的说明来操作,可能是后面赤的音我一开始就打完整了?因为我又重新做了一遍,发现确实是严格按照您的那个说明来操作的话,造不出这个词。(但是也有另一种可能,就是因为我修改了调整单字频率的代码,这样虽然严格按照您的操作步骤操作了,但也确实是没有造出这个词的。至于上面我说“造出了这个词”,可能是因为狄和赤两个字的频率都被调高了,恰好调整频率后的这两个字成了第一个备选词,看起来像是这个词被造出来了一样,但其实是没有造出这个词的)

所以我这边遇到的问题,大概就是对一个词只修改前面的音的话,是可以造出这个词的,但是如果修改这个词的最后一个字的音,就造不出这个词了。

emptiness.zip

如果您那边用传统的拼音方案,在两个字都修改的情况下可以造出这个词的话,那么,我想您要不要试试用我的输入方案(就是上面上传的这个文件)来操作,看是否会遇到这个问题?就打我上面回复中的皇氏和爱奇艺两个词就好,看是否会遇到我所说的问题?

@cjwdoing
Copy link
Author

cjwdoing commented Nov 5, 2018

@lotem 又看了一下代码,找到了比上面修订【调整单字优先度】的代码更好的方案。

稍微调试了一下,发现我遇到的问题最直接的原因是,Memory.cc中void Memory::OnCommit(Context* ctx)里面的commit_entry.Clear()这句代码。

相关的代码是这里:

  for (auto& seg : ctx->composition()) {
    auto phrase = As<Phrase>(Candidate::GetGenuineCandidate(
            seg.GetSelectedCandidate()));
    bool recognized = Language::intelligible(phrase, this);
    if (recognized) {
		commit_entry.AppendPhrase(phrase);
    }
    if (!recognized || seg.status >= Segment::
      commit_entry.Save();
      commit_entry.Clear();
    }
  }

比如一次输入四个字【比如“采办齐了”这四个字】,在前三个字已经确定的情况下对第四个字的编码进行修订(比如添加辅助码或者拼音)【比如先选中“采办”然后选中“齐”然后给“了”增加辅助码再选中】,这时会发现这四个字存储在了“composition”的两个元素中【“采办齐”三个字在一起,“了”单独一个;如果输入的是二字词语的话,会发现前后两个字分别存在一个compositon中】。因此下面 commit_entry.Save();的时候,就自然会把最后一个字单独分隔出来了。进而导致了最开始说的用辅助码调整文字后组词失败的问题。

暂时没有更仔细的去调试将最后一个字单独存在一个composition中的代码是哪里以及相应的逻辑是什么(主要是因为好像没有看到一个debug版的编译工具,稍微往前查了一下代码,好像在没有一个总的说明文档的情况下想要理顺全部的逻辑还是要稍微花些时间;如果能借助现有的glog调试信息的话应该也是可以相对容易的确定到哒~)。不过暂时的解决方案是,把commit_entry.Clear();这句话从循环里面拿出来,放到循环下面。这样就暂时的解决了最后一个字不参与组词的问题啦~

如果作者方便的话,还是希望可以指教一下将连续的文字放到不同composition中的拆分依据:-)

@st0nie
Copy link

st0nie commented Oct 23, 2023

https://gitea.stllokserver.synology.me/ston/rime-sp

使用这个方案的时候遇到了类似的问题,这个方案也是按照您的贴吧帖子制作的

问题是打词时,如果使用了tab移动后来选字,最后一个字如果使用了辅助码,那么会导致没法造词

比如打「巴勒」这个词,假设这个词不在我的用户词典中,我输入 bale<tab><space>g<space>
会发现勒被认为是一个单字,巴勒这个词并没有被加到用户词典中,而勒的词频提前了

如果输入bale<tab>s<space>g<space>无法加入到用户词典中,这相当于两个字都输入了辅助码
输入bale<tab>3g<space>无法记录到用户词典,相当于第一个字没有输入辅助码,第二个输入了辅助码
输入 bale<tab>s<space><space> 可以正常记录到用户词典,相当于第一个字用了辅助码,第二个字没有输入辅助码

使用 ' 来分割的话,可以正常造词

@ksqsf
Copy link
Contributor

ksqsf commented Mar 1, 2024

QQ羣裏剛討論到的,提供一個錄屏演示。

2024-03-01.15.21.47.mov

edit:嘗試手動刪詞重新操作後,相同的輸入產生的用戶詞典操作是:

image

也就是只更新了「長江 ih jd」「自流 zi lq」「空自流 ks zi lq」,其中只有「空自流」是新詞。如果要把整個句子作爲詞語記錄下來,這個詞就得打好幾遍。

@lotem lotem self-assigned this Mar 1, 2024
@lotem lotem changed the title 以tab键给前面的文字追溯增加辅助码后造词功能不能正常发挥作用 以tab键给前面的文字追溯修改輸入码后造词功能不能正常发挥作用 Mar 2, 2024
@lotem
Copy link
Member

lotem commented Mar 2, 2024

一說輔助嗎, 給問題搞複雜了. 透過現象看本質.

@lotem lotem transferred this issue from rime/home Mar 2, 2024
lotem added a commit to lotem/librime that referenced this issue Mar 2, 2024
call Context::BeginEditing when input is edited after selection.
move cursor also counts as edit.

the tag is used to tell if BackSpace should delete the last input
character or revert a recent selection.

the information was previously denoted by kConfirmed status which caused
the side-effect of breaking a user phrase into individual segments.

fixed rime#746, fixed rime#830
lotem added a commit to lotem/librime that referenced this issue Mar 2, 2024
call Context::BeginEditing when input is edited after selection.
move cursor also counts as edit.

the tag is used to tell if BackSpace should delete the last input
character or revert a recent selection.

the information was previously denoted by kConfirmed status which caused
the side-effect of breaking a user phrase into individual segments.

fixed rime#746, fixed rime#830
@lotem lotem closed this as completed in #831 Mar 2, 2024
lotem added a commit that referenced this issue Mar 2, 2024
call Context::BeginEditing when input is edited after selection.
move cursor also counts as edit.

the tag is used to tell if BackSpace should delete the last input
character or revert a recent selection.

the information was previously denoted by kConfirmed status which caused
the side-effect of breaking a user phrase into individual segments.

fixed #746, fixed #830
graphemecluster pushed a commit to TypeDuck-HK/librime that referenced this issue Mar 18, 2024
call Context::BeginEditing when input is edited after selection.
move cursor also counts as edit.

the tag is used to tell if BackSpace should delete the last input
character or revert a recent selection.

the information was previously denoted by kConfirmed status which caused
the side-effect of breaking a user phrase into individual segments.

fixed rime#746, fixed rime#830
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants