nanoで日本語のヘルプを表示させると応答がなくなる

Bug #188611 reported by Hajime Mizuno
2
Affects Status Importance Assigned to Milestone
Ubuntu Japanese Kaizen Project
Fix Released
High
Unassigned

Bug Description

- nano editor
日本語に翻訳したヘルプを表示すると、プログラムが無限ループになりアプリケーションの応答がなくなってしまう。
一行の文字数がカラム数を越えたときにポインタを直前のスペースまで戻して改行する処理がありますが、日本語の場合は文中にスペースが存在しないため、一行の最大文字数を越える長さの文を表示させようとすると行の先頭にポインタが戻ってしまい、無限ループになってしまいます。

Changed in ubuntu-jp-improvement:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

nanoの改行処理(こういう文脈での"wrap"の一般的な訳語ってなんですか?)

・通常のテキストの場合(do_wrap)
カラム数を越えない改行可能文字(スペースやタブ、改行コードや終端文字)を探しだし、
その文字の次の文字以降を、次の行に表示する。
例:"abcd_efghijk"を6文字幅で表示しようとすると
abcd_
efghijk
となる。ここでアンダースコアは空白文字をあらわしている。
2行目のように改行可能文字が見つからなかった場合、
カラム数よりも後ろの改行可能文字を探してそこで改行を行う。

・ヘルプ用のテキストの場合(do_help)
カラム数を越えない改行可能文字(スペースやタブ)を探しだし、
その文字以降を、次の行に表示する。
例:"abcd_efghijk"を6文字幅で表示しようとすると
abcd
_efghijk
となる。ここでアンダースコアは空白文字をあらわしている。
つまり、2行目以降は必ず改行文字が含まれてしまうため、
通常のテキストのような「改行可能文字が見つからない」という処理が行われない。
よって、「文頭にのみ改行可能文字があるよ」
→「じゃ文頭の空白"以降を"次の行にもってこようか
→「次の行の、カラム数を越えない場所にある改行可能文字を探して」
→「文頭にのみ改行可能文字があるよ」
というコントを行う。

----
主に自分用に少し噛み砕いてまとめてみました。本当は解決策まで用意するつもりでいたのですが、良い案を思い浮かべずに挫折です。そもそも、nanoがやっている改行処理(通常テキスト・ヘルプ用テキストの両方)は、日本語と非常に相性が悪いように思います。ヘルプ用のテキストを通常のテキストと同じような処理にしたとしても、中途半端なところで改行されてガタガタだわ、空白のない長い文字列はそのまま画面の右の方に溢れて見えないだわの、とても読みにくいヘルプになってしまいますし。

nanoに大改修を行うよりは、翻訳ファイルの方で半角換算で79文字幅ごとに半角スペースを1つ入れるという回避策を使った方がいいかもしれません。

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

とりあえず、強制的に改行するパッチを作ってみました。

Hardyを使っている場合は、レポジトリに↓を追加すれば、
パッチ適用済みの2.0.7-0ubuntu1~ppa7がインストールされます
deb http://ppa.launchpad.net/cosmos-door/ubuntu hardy main

ヘルプを表示時、カラム数を越えない改行可能位置が見つからない場合は、
強制的にカラムを越えないように改行を行うパッチです。
ただ、この場合、行頭に空白が含まれないので、見た目が悪くなります。
ただ、翻訳文には半角空白を含まないようにすれば、
もう少し見た目はよくなるかもしれません。

このやりかたでもいいのなら、上流に報告してみようと思います

Revision history for this message
Hajime Mizuno (mizuno-as) wrote :

パッチを適用したパッケージをインストールして確認しました。端末の大きさ変更しても、きちんと折り返しされているようです。
見た目の問題については、私はそれほど気にならなかったのですが、如何でしょう?
厳密に見た目を考え出すと、端末サイズによっては行頭に句読点が来てしまうこともあるので、そこまで考えないといけなくなってしまいそうで。

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

とりあえずパッチはnanoの開発元に送ってみました。ただ、開発自体が活発ではないようなので、今後どうなるかはわかりません。たとえパッチ適用済みバージョンがリリースされたとしてもHardyには間に合いませんので、Ubuntuのnanoにも独自にパッチを当てる必要がありますね。

ちなみに、見た目は次のようになります(実際は等幅で表示されます)。
どれがいいかコメントしていただけるとありがたいです。

a) 英語版
Main nano help text

 The nano editor is designed to emulate the functionality and ease-of-use of
 the UW Pico text editor. There are four main sections of the editor. The top
 line shows the program version, the current filename being edited, and whether
 or not the file has been modified. Next is the main editor window showing the
 file being edited. The status line is the third line from the bottom and
 shows important messages. The bottom two lines show the most commonly used
 shortcuts in the editor.

 The notation for shortcuts is as follows: Control-key sequences

b) 翻訳ファイルの方で半角79文字幅ごとに半角空白をいれた場合
nano のヘルプ

 nano はワシントン大学で開発された Pico エディタの機能性と使いやすさを見習って
 開発されました。nano の画面には 4 つのセクションがあり、一番上の行には nano の
 バージョン、編集中のファイル名、最後に保存されてから変更が行われたか否かが表示
 されています。次にファイルを編集する領域があります。下から三行目はステータス行
 で、重要なメッセージが表示されます。 画面下部の二行には、一般的に使われるショ
 ートカットキーが表示されています。

c) 無限ループを気合で逃げた場合
nano のヘルプ

 nano はワシントン大学で開発された Pico
 エディタの機能性と使いやすさを見習って開発されました。nano の画面には 4
 つのセクションがあり、一番上の行には nano
 のバージョン、編集中のファイル名、最後に保存されてから変更が行われたか否かが(以下消滅)
 画面下部の二行には、一般的に使われるショートカットキーが表示されています。

d) パッチを適用した場合
nano のヘルプ

 nano はワシントン大学で開発された Pico
 エディタの機能性と使いやすさを見習って開発されました。nano の画面には 4
 つのセクションがあり、一番上の行には nano
 のバージョン、編集中のファイル名、最後に保存されてから変更が行われたか否かが表
示されています。次にファイルを編集する領域があります。下から三行目はステータ
行で、重要なメッセージが表示されます。
 画面下部の二行には、一般的に使われるショートカットキーが表示されています。

e) パッチを適用しかつ翻訳ファイルの文中の半角空白を削除した場合
nano のヘルプ

 nanoはワシントン大学で開発されたPicoエディタの機能性と使いやすさを見習って開発
されました。nanoの画面には4つのセクションがあり、一番上の行にはnanoのバージョン
、編集中のファイル名、最後に保存されてから変更が行われたか否かが表示されています
。次にファイルを編集する領域があります。下から三行目はステータス行で、重要なメッ
セージが表示されます。
 画面下部の二行には、一般的に使われるショートカットキーが表示されています。

Revision history for this message
Hajime Mizuno (mizuno-as) wrote :

(b)は端末サイズが79文字以下だった場合を考えると問題がありそうです。
(c)は消えてしまう部分があるので問題だと思います。
(d)は問題ないですが、翻訳する際に半角英数字の前後を分かち書きしているのが仇になってしまっている感じですね。
見た目で言えば(e)が一番いいと思いますが、今後誰かが訳文を修正したりする際に、この問題を知らないと困ってしまいますね。
(Launchpad のスペース挿入の指示どおりに翻訳するとまずい)

理想的には(e)ですが、(d)でも運用上の問題はないかな、と思います。

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

言われてみれば、確かに(b)は明らかにダメですねorz

>(Launchpad のスペース挿入の指示どおりに翻訳するとまずい)
この部分がよくわからないんですけど、例えば上記の例だと、
https://translations.launchpad.net/ubuntu/hardy/+source/nano/+pots/nano/ja/210/+translate
スペースを入れろと指示しているのは文頭一つと文末二つ(=水色の丸の場所)だけですよね?

(e)はこのスペースに関してはそのまま残っていることを前提に整形していますので、
英単語の前後のスペースをいれないようにすれば問題ないと思います。
英単語が続く文章を使わざるを得ない部分がヘルプにある場合は
どうしようもないですけど……。

とりあえず、(d)でも(e)でもプログラムの方への修正は同じですので、
あとは翻訳者がどうするか、ですね。

Revision history for this message
Hajime Mizuno (mizuno-as) wrote :

>(e)はこのスペースに関してはそのまま残っていることを前提に整形していますので、
>英単語の前後のスペースをいれないようにすれば問題ないと思います。

一つの msgid の中に複数の文があり、その中の(二番目以降の文の先頭に)スペースがあるものがあったと記憶しているので、問題があるかと思ったのです。

>英単語が続く文章を使わざるを得ない部分がヘルプにある場合は
>どうしようもないですけど……。

英単語が連続するのは「Page Up キー」のような訳文だけだと思います。
この程度でしたらスペースを入れず、CamelCase で逃げられそうです。
問題がないようでしたら翻訳文からスペースを剥ぎ取ってみようと思いますがいかがでしょうか?

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

文頭にスペースがあるのは、改行コード後の文頭もインデントさせるためですね。強制改行させる場合は、あってもなくても最初の行だけ半角分インデントされるかどうかの違いが生じるだけになると思います。

>問題がないようでしたら翻訳文からスペースを剥ぎ取ってみようと思いますがいかがでしょうか?
というわけで、そうしていただけると助かります

Revision history for this message
Hajime Mizuno (mizuno-as) wrote :

作業完了しました。
こちらで確認した範囲では、問題なく表示されているようです

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

バグとして登録し、修正版のdiff.gzファイルを添付しました。
問題がなければ、ベータリリース以降にアップロードされると思います。
たぶん、ベータには間に合いません。

https://bugs.launchpad.net/ubuntu/+source/nano/+bug/201769

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

This bug was fixed in the package nano - 2.0.7-1ubuntu1

---------------
nano (2.0.7-1ubuntu1) hardy; urgency=low

  * debian/patches/01_helpwrapping:
    - To avoid to freeze when fail to find blank character,
      force line break. (LP: #201769, #188611)

Changed in ubuntu-jp-improvement:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.