Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

histedit と日本語ログメッセージ

82 views
Skip to first unread message

Shun-ichi GOTO

unread,
Feb 12, 2014, 4:14:51 AM2/12/14
to mercur...@googlegroups.com
後藤です

普段使わない histedit を使ってたら、奇妙な現象に悩まされたのでパッチを作
りました。本家にパッチを投げる前にご意見を聞いておきたく。

症状としては、一言で言うと漢字のコミットメッセージだとよろしくないことが
ある、というやつです。

もう少し言うと、hg histedit コマンド実行で、編集指示用のテキストファイル
をエディタで開きますが、これが2バイト目を失った不完全なSJISのテキストとな
ることがあるという症状

emacsなどのような自動文字コード検出のものだとsjisと解釈されずにバケバケな
状態で操作することになったりで不幸です。

そんなのを解消する修正です。


diff -r eabc83d5a8c5 hgext/histedit.py
--- a/hgext/histedit.py Wed May 15 17:16:11 2013 +0900
+++ b/hgext/histedit.py Wed Feb 12 18:04:59 2014 +0900
@@ -161,6 +161,7 @@
from mercurial import merge as mergemod
from mercurial.lock import release
from mercurial.i18n import _
+from mercurial.encoding import ucolwidth, encoding

cmdtable = {}
command = cmdutil.command(cmdtable)
@@ -735,6 +736,15 @@
fp = open(os.path.join(repo.path, 'histedit-state'))
return pickle.load(fp)

+def trim(s, c):
+ """trim a string `s` within `c` columns
+ """
+ us = s.decode(encoding, 'replace')[:c]
+ w = ucolwidth(us)
+ while c < w:
+ us = us[:-1]
+ w = ucolwidth(us)
+ return us.encode(encoding)

def makedesc(c):
"""build a initial action line for a ctx `c`
@@ -747,7 +757,8 @@
if c.description():
summary = c.description().splitlines()[0]
line = 'pick %s %d %s' % (c, c.rev(), summary)
- return line[:80] # trim to 80 chars so it's not stupidly wide in my editor
+ from mercurial.encoding import getcols
+ return trim(line, 80) # trim to 80 chars so it's not stupidly wide in my editor

def verifyrules(rules, repo, ctxs):
"""Verify that there exists exactly one edit rule per given changeset.


類似のチョッピングは他にもありそうだけどまだ探してません。
あるなら、trim()は encoding に置くべきなのかも。

--
Shun-ichi Goto

Katsunori Fujiwara

unread,
Feb 12, 2014, 6:37:34 AM2/12/14
to mercurial-ja
藤原です。

気になったので、ソースをざっくりと確認してみました。

流石に "[n:m]" 形式全部の確認は、早々にあきらめましたが(w)、"[:"
との合致で怪しそうなものは、私が探した範囲では、histedit のものを
含め、以下の2箇所ぐらいでした。

    hgext/histedit.py:750:    return line[:80]  # trim to 80 chars so it's not stupidly wide in my editor
    hgext/progress.py:183:        sys.stderr.write('\r' + out[:termwidth])

数は少ないですが、今後の再利用を考えると、trim() 処理は
encoding に置いた方が良いでしょうね。



2014年2月12日 18:14 Shun-ichi GOTO <go...@taiyo.co.jp>:

--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。
このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。



--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

Katsunori Fujiwara

unread,
Feb 12, 2014, 7:01:14 AM2/12/14
to mercurial-ja
藤原です。

メールを出してから、「そう言えば qseries -s でも、説明行の切捨てを
やっていたなぁ」と思い出して確認してみたところ、こちらは
util.ellipsis() を使っていました。

    http://selenic.com/repo/hg/file/78f4c2b7052f/hgext/mq.py#l1721

「encoding ではなく util ?」と思ったのですが、ellipsis() は
カラム幅ではなく文字数で切り落としていました。

    http://selenic.com/repo/hg/file/78f4c2b7052f/mercurial/util.py#l1280

「MQ + 日本語ログ + qseries -s」の組み合わせは、多分使ったことが無
いので、全然気が付きませんでした…… > 文字数切り落とし

これも、非 ascii 対応しておいた方が良いでしょうね。

処理を共有するなら trim(text, colwidth, trailer=None) みたいな感じ
で、切り落とし時の追加文字列も指定できた方が便利そう。



2014年2月12日 20:37 Katsunori Fujiwara <flying...@gmail.com>:



--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

Katsunori Fujiwara

unread,
Feb 12, 2014, 7:10:00 AM2/12/14
to mercurial-ja
藤原です。

細切れで済みません。

再度確認してみたら、多くの処理が util.ellipsis() を呼んでいるので:

  (1) util.ellipsis() の「カラム幅判定の適正化」と
  (2) histedit/progress での util.ellipsis() 利用

を対応すれば良さそうな感じです。



2014年2月12日 21:01 Katsunori Fujiwara <flying...@gmail.com>:



--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

Shun-ichi Goto

unread,
Jun 5, 2014, 5:22:21 AM6/5/14
to mercurial-ja
2014年2月12日 21:10 Katsunori Fujiwara <flying...@gmail.com>:
> 再度確認してみたら、多くの処理が util.ellipsis() を呼んでいるので:
>
> (1) util.ellipsis() の「カラム幅判定の適正化」と
> (2) histedit/progress での util.ellipsis() 利用
>
> を対応すれば良さそうな感じです。

ずいぶん浦島なレスですが、twitterで話が出ましたので、そっちではやりにくかったので
こちらへ移動します。

> ちなみに以前MLに投函されていた「文字列切り落とし処理の i18n 対応」 https://groups.google.com/d/msg/mercurial-ja/n8Vpls3mNqA/Q1NcQqiGRuoJ … はどんな状況でしょうか?

どんな状況か、というと、「すっかり忘れてました」ですね。
でも一応 util.ellipsis() での対応と、histeditでのそれの利用という形のパッチにはしてあって、
テストをどうしようかなぁ、あたりでそこで保留にしたままでした。

> 特に進展が無いようであれば、類似問題として、一緒に修正提案してみようと思いますが如何でしょうか?

できれば進めていただけるとありがたいです。
手元のパッチを一応添付しておきます。使っても捨てても結構です。
こちらを気にすること無くどうぞ。

テストも一応書いてあるのですが mercurial 方式ではない、doctestによるオレオレテストです。

--
Shun-ichi GOTO
ellipsis-wide-chars
histedit-trim
Reply all
Reply to author
Forward
0 new messages