"不負責"自由軟體中文輸入法改進規劃:

下面是我目前比較關心的: (我之前還列出重覆輸出，後來不知道怎樣了。)

1. 列出同音字待選
2. 編打編唸 (用語音確認)
3. 放大輸入緩衝區 (這樣user 可以少按幾次輸出鍵)

第一個 在我提出feature request 後, gcin 的作者已經實作出來了，太帥了。新酷音好像還沒看到。
第二個 工程浩大，但我一直有在設法集合各方力量去實作，包括結合圖書館界想要作無障礙閱讀環境的資源。除了基本的收集標準語音外(402 個基本音，加上四聲變化，會少於 400x5=2000個音)，
在Linux 上，還需要聯接Alsa API，我覺得最好能支援用Jack IT ，因為怕多工環境下延遲
第三個 其實我沒很大把握，因為我還沒從頭到尾trace 過gcin 跟新酷音的原碼，不瞭解取詞的演算法 ....先當我是小白好了，所以這篇取名"不負責"...規劃。已經做好心裡準備被罵搞不清狀況，不過至少當豬頭拋磚引玉，應該比光要人改進，但連實作規畫都沒有的來的強一點點。

想法從下面節錄新酷音兩位網友的討論引申出來，要在便利跟效率中取得平衡:
有沒有可能改成，把大的緩衝區分成兩部份，在M 字輸入緩衝區中(比如說 M=45)，只look ahead 最接近游標的 N (=15)字主緩衝區? N <=M 。一直輸入不後退超過了N 字的話，緩衝區前面(M-N) 字就暫時放到次緩衝區去 (移 link-list 的指標就好，其實沒有copy 資料的動作) 次緩衝區暫時不能改。假如使用者游標一直退到前 m-n 個字串範圍裡，主緩衝區跟次緩衝區會跟著變動，主緩衝區只look ahead 最接近游標的n 字

這樣只會constant-time slow : up to 2^N = 2^15 外加上 "雙緩衝區" (這我不知該如何解釋)的overhead， 應該是 linear time

能不能實做還是要看新酷音的原碼，其實不是不想，但以前就說了，沒有註解的C程式 我實在吃不消

---------------------------

windows_usr wrote:
> > 我用的是win32的最新win32-chewing-0.3.4.2.exe版本，說明裡寫著輸入一整句後按Enter,但我發現每輸入15個字就會
> > 自動送出超過此長度的字串。句子一般長度也有25-50個字吧，15個字真的太少了，打字時常常需要翻看，因為怕字自動送出了，沒有修改的機會，這樣很
> > 大地影響打字速度。酷音輸入法真的很好用，希望開發組可以加入自訂自動送出字串長度的功能。

Kuang-che Wu wrote:
> > On Thu, Apr 26, 2007 at 04:28:35AM -0700, windows_usr wrote:
>> >> 普通句子長度是25-35個字，加上夾雜一些英文。我想最好有45個字的buffer。
> >
> > 現在 libchewing 的運作原理, 當太長的話可能會很慢 (接近 2^n 的速度成長)
> >
> > 你可以試試看輸入
> >
> > 程式程式程式程式....
> >
> > 一整串, 越長會越慢, 在 input line 快滿那時, 速度已經慢到可以察覺.
> > 再更長的話, 可能就會慢到無法接受了